<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 28, 2014 at 9:04 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Following Mikhail Glushenkov's advice I have prepared a separate tool that checks PVP compliance of imports as proposed in:<br>


  <a href="https://github.com/haskell/cabal/issues/1703" target="_blank">https://github.com/haskell/<u></u>cabal/issues/1703</a></blockquote><div><br></div><div>I added some feedback in this bug, before I saw this email.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* How can I exclude automatically generated modules like Path_*.hs from the check?<br></blockquote><div><br>

</div><div>Somewhere in the code there's a function for getting them. Unfortunately I don't remember where. Not very helpful, I know.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

* How can I access modules that are preprocessed? HSC processed modules are stored in dist/build, but CPP processed modules are not stored anywhere.<br></blockquote><div><br></div><div>Perhaps because GHC applies CPP "on the fly". I guess you prefer to use haskell-src-exts, but using the GHC API might be better in the long run, as your tool will work on all packages (more or less a requirement for cabal integration.)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* How shall I cope with condition flags? Currently I use flattenPackageDescription. Alternatively I might only check the modules that are part of the current configuration. But I may miss many modules this way. I might perform checks on all possible configurations.<br>


<br>
* Can you give me advice on what I shall write to stdout and what to stderr? The purpose of the program is to generate a list of warnings. Shall they be written to stderr because they are warnings or shall they be written to stdout because they are the intended output of the program?<br>

</blockquote><div><br></div><div>I think it depends on the context where this is run. If it was part of cabal check, stderr. If it's a standalone tool, perhaps stdout.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

* Regarding levels of verbosity: How silent shall silent be? Shall the test results be emitted in silent mode or only in normal verbosity mode?<br></blockquote><div><br></div><div>By test results you mean your warnings? I think we should consider making this part of cabal check. I think we might want to only run it on the library section for now and only optionally (i.e. using a flag) check test-suites etc. The PVP really only applies to libraries.</div>

<div><br></div><div>-- Johan</div><div><br></div></div></div></div>