darcs patch: Add initial support for
--enable/disable-library-vanilla
Simon Marlow
simonmarhaskell at gmail.com
Thu Aug 3 03:59:24 EDT 2006
On 02 August 2006 19:09, Duncan Coutts wrote:
> On Tue, 2006-08-01 at 12:12 +0100, Simon Marlow wrote:
>> Duncan Coutts wrote:
>>> Specifically: if the user asks for profiling but not vanilla
>>> versions of libs and they're using TH then we should build vanilla
>>> libs first and then profiling libs. However at install time we
>>> would not install the vanilla libs as the user did not ask for them.
>>
>> Yes, that's right.
>>
>>> Simon: what about if we're building a program rather than a lib?
>>> Should we vanilla-compile all the modules but not link then into a
>>> binary and then compile again with profiling and then link those
>>> into a binary?
>>
>> I would think so, yes. Just build with --make -c for the vanilla
>> way.
>
> Ok I've got a patch attached that does this.
>
>>> And presumably we would only expect this to work with GHC 6.6.
>>
>> Yes. I'd appreciate it if someone could test this with a TH program
>> and 6.6, to make sure that GHC can find the vanilla object files
>> correctly.
>
> Should I expect this to work now or is it still unfinished work for
> 6.6 ?
Yes, it should work now. I've turned on the profiling way for our TH
tests, and they are passing right now.
> I've added a trac ticket so we don't forget the testing:
>
> http://hackage.haskell.org/trac/hackage/ticket/91
Which reminds me of a question I have in general: what's the testing
strategy for Cabal? I'm aware of the unit tests (which I use via GHCi).
'make moduleTest' spews a ton of stuff, including lots of messages about
failures, and I'm not sure whether I should expect it to work or not.
In GHC we have a small number of tests in our testsuite for
Cabal-related things
(http://darcs.haskell.org/testsuite/tests/ghc-regress/cabal). Perhaps
we should try to incorporate the other Cabal tests into there too?
Cheers,
Simon
More information about the cabal-devel
mailing list