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?


More information about the cabal-devel mailing list