darcs patch: Add initial support for --enable/disable-library-vanilla
Patches from Jeremy Shaw. Duncan, can you look at these and apply?
On Thu, 2006-07-20 at 11:49 -0700, Isaac Jones wrote:
Patches from Jeremy Shaw. Duncan, can you look at these and apply?
The patch looks mostly ok to me. So it just turns on or off the building of normal libs. The TH thing - can we check that this is really the right thing to do? So the code is forcing normal libs to be built when the library uses TH (even if the user didn't want to build normal libs). Note that they've not got a fix for this yet in GHC: http://www.haskell.org/pipermail/template-haskell/2003-July/000135.html http://www.haskell.org/pipermail/template-haskell/2005-July/000466.html http://hackage.haskell.org/trac/ghc/ticket/651 So we should check with the GHC devs that the behaviour in this patch will need to be part of any solution. Otherwise it seems a bit preemptive. Duncan
On Fri, 2006-07-21 at 16:00 +0100, Duncan Coutts wrote:
On Thu, 2006-07-20 at 11:49 -0700, Isaac Jones wrote:
Patches from Jeremy Shaw. Duncan, can you look at these and apply?
The patch looks mostly ok to me. So it just turns on or off the building of normal libs.
The TH thing - can we check that this is really the right thing to do?
So the code is forcing normal libs to be built when the library uses TH (even if the user didn't want to build normal libs).
Note that they've not got a fix for this yet in GHC:
http://www.haskell.org/pipermail/template-haskell/2003-July/000135.html http://www.haskell.org/pipermail/template-haskell/2005-July/000466.html
http://hackage.haskell.org/trac/ghc/ticket/651
So we should check with the GHC devs that the behaviour in this patch will need to be part of any solution. Otherwise it seems a bit preemptive.
Since no one said anything I've committed the patch but without the TH bit and with some other minor changes. Duncan
Duncan Coutts
On Fri, 2006-07-21 at 16:00 +0100, Duncan Coutts wrote:
On Thu, 2006-07-20 at 11:49 -0700, Isaac Jones wrote:
Patches from Jeremy Shaw. Duncan, can you look at these and apply?
The patch looks mostly ok to me. So it just turns on or off the building of normal libs.
The TH thing - can we check that this is really the right thing to do?
So the code is forcing normal libs to be built when the library uses TH (even if the user didn't want to build normal libs).
Note that they've not got a fix for this yet in GHC:
http://www.haskell.org/pipermail/template-haskell/2003-July/000135.html http://www.haskell.org/pipermail/template-haskell/2005-July/000466.html
http://hackage.haskell.org/trac/ghc/ticket/651
So we should check with the GHC devs that the behaviour in this patch will need to be part of any solution. Otherwise it seems a bit preemptive.
Since no one said anything I've committed the patch but without the TH bit and with some other minor changes.
OK. I've CC'd Simon so he can lend is $0.02 about the TH stuff. peace, isaac
On Fri, 2006-07-28 at 11:30 -0700, Isaac Jones wrote:
The TH thing - can we check that this is really the right thing to do?
So the code is forcing normal libs to be built when the library uses TH (even if the user didn't want to build normal libs).
Note that they've not got a fix for this yet in GHC:
http://www.haskell.org/pipermail/template-haskell/2003-July/000135.html http://www.haskell.org/pipermail/template-haskell/2005-July/000466.html
http://hackage.haskell.org/trac/ghc/ticket/651
So we should check with the GHC devs that the behaviour in this patch will need to be part of any solution. Otherwise it seems a bit preemptive.
Since no one said anything I've committed the patch but without the TH bit and with some other minor changes.
OK. I've CC'd Simon so he can lend is $0.02 about the TH stuff.
I caught Simon on irc the other day and he thought that this sounds like the right behaviour. 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. 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? And presumably we would only expect this to work with GHC 6.6. Duncan
Duncan Coutts wrote:
On Fri, 2006-07-28 at 11:30 -0700, Isaac Jones wrote:
The TH thing - can we check that this is really the right thing to do?
So the code is forcing normal libs to be built when the library uses TH (even if the user didn't want to build normal libs).
Note that they've not got a fix for this yet in GHC:
http://www.haskell.org/pipermail/template-haskell/2003-July/000135.html http://www.haskell.org/pipermail/template-haskell/2005-July/000466.html
http://hackage.haskell.org/trac/ghc/ticket/651
So we should check with the GHC devs that the behaviour in this patch will need to be part of any solution. Otherwise it seems a bit preemptive.
Since no one said anything I've committed the patch but without the TH bit and with some other minor changes.
OK. I've CC'd Simon so he can lend is $0.02 about the TH stuff.
I caught Simon on irc the other day and he thought that this sounds like the right behaviour.
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.
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. Cheers, Simon
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 ? I've added a trac ticket so we don't forget the testing: http://hackage.haskell.org/trac/hackage/ticket/91 Duncan
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:
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
Simon Marlow
I've added a trac ticket so we don't forget the testing:
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?
The cabal test suite is actually still pretty good and non bitrotted. There are 3 tests I think that fail, and I haven't gotten around to figuring out why yet. When I add new features, I always add tests, though I know that most people don't, so there are probably lots of untested features. The test suite should basically work if you have ghc and hugs installed. "make check" does everything and reports on failures at the end. The hugs tests will often fail a lot if Hugs has an older version of cabal installed. This can be fixed by building and installing the current tree for Hugs like normal: ./setup configure --hugs ./ etc peace, isaac
participants (3)
-
Duncan Coutts -
Isaac Jones -
Simon Marlow