check-pvp

Henning Thielemann lemming at henning-thielemann.de
Sat Mar 1 21:40:46 UTC 2014


Am 01.03.2014 22:29, schrieb Roman Cheplyaka:
> * Henning Thielemann <lemming at henning-thielemann.de> [2014-03-01 19:02:35+0100]
>> I got some problems. Using NamesDB as in hs-gen-iface works, but I
>> guess, I do not need NamesDB and thus haskell-names.
>
> Certainly not.
>
> Perhaps the compiler abstraction is not such a good fit for check-pvp.
>
> For a usual compiler, you need your dependencies to be installed. For
> check-pvp, you don't.

I need the packages installed, since if I find the dependency

    containers >=0.5 && <0.6

I need to know the modules belonging to "containers" in order to check 
imports of them. However, there is no need to run "check-pvp" on the 
imported packages - this is what cabal-install with check-pvp-compiler 
currently tries to do.

 > And, as you note, check-pvp doesn't produce any artifacts either.

That's true. However, if haskell-package insists on a result per module 
I could write a test report for each module into a corresponding file.


> I guess a new abstraction (and a new command, similar to build)
> should be added to haskell-packages to support such use cases. I have to
> think about this. (TBH I'm too concerned with what's happening to my
> country right now to think clearly.)

I see.


> If you have any suggestions, let me know. Are there any similar use
> cases to this one, or is it too different from anything else? In other
> words, is it worth it to create an abstraction for this?

So far I find the idea appealing to use the infrastructure for doing all 
the preprocessing. There might be more analysis tools that work the same 
way, but I have no concrete plans.



More information about the cabal-devel mailing list