Am 01.03.2014 22:29, schrieb Roman Cheplyaka:
* Henning Thielemann <lemm...@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.
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
