"Setup.lhs: hope.cabal has been changed, please re-configure."
Hello, Thanks for your efforts with Cabal, it seems to work really well. Can I suggest a few improvements to the above error message: 1. Provide a flag "--force" that says "OK, the user knows best." (Sometimes I change the .cabal file trivially, and really just want to build the thing.) Indeed, a lot of commands might usefully be "--force"d. 2. It is a bit unsound to say "please re-configure". You may also need to "clean", if in fact the .cabal file has changed significantly. So, to say that another way, the message provides both insufficient and unnecessary advice, but I think it can be improved. cheers peter
On Wed, 2007-12-19 at 15:57 +0700, Peter Gammie wrote:
Hello,
Thanks for your efforts with Cabal, it seems to work really well.
Can I suggest a few improvements to the above error message:
1. Provide a flag "--force" that says "OK, the user knows best." (Sometimes I change the .cabal file trivially, and really just want to build the thing.) Indeed, a lot of commands might usefully be "--force"d.
Hmm, I'd rather not add a --force to anything. Where else would you want --force? Ideally we would just do whichever bits of re-configuring that are necessary. With a dependency framework this should be quite possible as we could treat each field in the .cabal file as a separate bit of info with it's own timestamp etc.
2. It is a bit unsound to say "please re-configure". You may also need to "clean", if in fact the .cabal file has changed significantly.
Really? Under what circumstances would that be necessary?
So, to say that another way, the message provides both insufficient and unnecessary advice, but I think it can be improved.
How about just re-running configure if we think it's necessary, and using the previous configuration flags? Duncan
On 19/12/2007, at 5:18 PM, Duncan Coutts wrote:
On Wed, 2007-12-19 at 15:57 +0700, Peter Gammie wrote:
Hello,
Thanks for your efforts with Cabal, it seems to work really well.
Can I suggest a few improvements to the above error message:
1. Provide a flag "--force" that says "OK, the user knows best." (Sometimes I change the .cabal file trivially, and really just want to build the thing.) Indeed, a lot of commands might usefully be "--force"d.
Hmm, I'd rather not add a --force to anything. Where else would you want --force?
Sorry, I typed that out without thinking too hard. "configure" is another spot. I'm currently hacking a project with a lot of darcs-repo dependencies. Sometimes I do a "darcs pull" and the version requirements have changed, so I have to go and rebuild / install other packages. It's sometimes useful to say "hang it, just try to build it with what's already there". - in particular with e.g. HaXml, which has a lot of dependencies that I believe are satisfied in "base" for GHC 6.6.1, but is supplied with a .cabal file that doesn't take care to find them (presumably it works for 6.8.x). This might be problematic for generating the GHC command line, I guess. Perhaps you could have a sloppy mode where you don't do any package hiding. (In the case of HaXml I'm really just interested in building the doc's and seeing if they've added anything that requires a newer GHC, etc.)
2. It is a bit unsound to say "please re-configure". You may also need to "clean", if in fact the .cabal file has changed significantly.
Really? Under what circumstances would that be necessary?
Ah, I remember now. Imagine this, similar to the above (I don't have to, I do this all the time :-): - see a new version of something, update the cabal file to reflect new version. - we say "build", we get asked to "configure", so we do. - if the API didn't change, then "build" does nothing, as GHC doesn't track dependencies across packages. (at this point you may say that GHC should be ... adjusted, but I don't know what's involved.) - then "install" might go through, but the higher-up library users may fail to link or screw up in magical mystical ways due to out-of-date dependencies at this level. I hope that is clear. While hacking HSQL and HaskellDB I ran into this problem all the time, so I usually did clean/configure/build/haddock/ install all the time, which is no fun on one package let alone the 6 or so in that chain. Also there was no way to be sure that I'd recompiled them in the right order. For a release I expect the versioning takes care of that. Actually, how about a command that does all that in one go? Something like: runghc Setup buildAll <configure options> (I'm not proposing you fix things in the way I suggest, just that you provide a mechanism for doing this sort of thing directly in Cabal.)
So, to say that another way, the message provides both insufficient and unnecessary advice, but I think it can be improved.
How about just re-running configure if we think it's necessary, and using the previous configuration flags?
I think it best that you *don't* do that for a usual "build", but if we're using something like "buildAll" then perhaps. A flag - "go ahead and generally clobber things as you see best" - might be handy for developers too. I for one would prefer to wait a bit longer if I'm guaranteed I'll get something useable (i.e. none of these issues) at the end of the process. Sorry if this is well-worn ground. I'm quite surprised how well Cabal works at the end-user stage, and I guess my complaints are really levelled at GHC's dependency tracking, which makes hacking less safe than I'd like. cheers peter
On Wed, 2007-12-19 at 18:12 +0700, Peter Gammie wrote:
On 19/12/2007, at 5:18 PM, Duncan Coutts wrote:
On Wed, 2007-12-19 at 15:57 +0700, Peter Gammie wrote:
Hello,
Thanks for your efforts with Cabal, it seems to work really well.
Can I suggest a few improvements to the above error message:
1. Provide a flag "--force" that says "OK, the user knows best." (Sometimes I change the .cabal file trivially, and really just want to build the thing.) Indeed, a lot of commands might usefully be "--force"d.
Hmm, I'd rather not add a --force to anything. Where else would you want --force?
Sorry, I typed that out without thinking too hard.
"configure" is another spot. I'm currently hacking a project with a lot of darcs-repo dependencies. Sometimes I do a "darcs pull" and the version requirements have changed, so I have to go and rebuild / install other packages. It's sometimes useful to say "hang it, just try to build it with what's already there". - in particular with e.g. HaXml, which has a lot of dependencies that I believe are satisfied in "base" for GHC 6.6.1, but is supplied with a .cabal file that doesn't take care to find them (presumably it works for 6.8.x).
The right solution is for Cabal to do it's own dependency analysis and to be able to build a collection of related packages. Then you would not need to cut corners "hang it, just try to build it with what's already there". Of course we're not near doing that yet.
(In the case of HaXml I'm really just interested in building the doc's and seeing if they've added anything that requires a newer GHC, etc.)
In the case of HaXml use the 1.13.3 version was updated to use the new split base libs but not to use configurations so it would also build with ghc-6.6. Hopefully we can persuade Malcolm to upload a .4 that uses configurations and works with both.
2. It is a bit unsound to say "please re-configure". You may also need to "clean", if in fact the .cabal file has changed significantly.
Really? Under what circumstances would that be necessary?
Ah, I remember now. Imagine this, similar to the above (I don't have to, I do this all the time :-):
- see a new version of something, update the cabal file to reflect new version. - we say "build", we get asked to "configure", so we do. - if the API didn't change, then "build" does nothing, as GHC doesn't track dependencies across packages.
(at this point you may say that GHC should be ... adjusted, but I don't know what's involved.)
Right, this is cross-package dependencies.
- then "install" might go through, but the higher-up library users may fail to link or screw up in magical mystical ways due to out-of-date dependencies at this level.
I hope that is clear. While hacking HSQL and HaskellDB I ran into this problem all the time, so I usually did clean/configure/build/haddock/ install all the time, which is no fun on one package let alone the 6 or so in that chain. Also there was no way to be sure that I'd recompiled them in the right order. For a release I expect the versioning takes care of that.
Actually, how about a command that does all that in one go? Something like:
runghc Setup buildAll <configure options>
Yes, so this is what I was talking about above, building a collection of related packages, respecting their dependencies. This needs a proper dependencies infrastructure in Cabal, which is the next major architectural project in Cabal and is something we need more help with. Many new features are blocking on this. http://hackage.haskell.org/trac/hackage/ticket/15 http://hackage.haskell.org/trac/hackage/ticket/104 http://hackage.haskell.org/trac/hackage/ticket/110 http://hackage.haskell.org/trac/hackage/ticket/128 http://hackage.haskell.org/trac/hackage/ticket/159 http://hackage.haskell.org/trac/hackage/ticket/171 Duncan
In the case of HaXml use the 1.13.3 version was updated to use the new split base libs but not to use configurations so it would also build with ghc-6.6. Hopefully we can persuade Malcolm to upload a .4 that uses configurations and works with both.
I have actually tried to use configurations for HaXml's cabal file, but I'm a bit stuck. I don't know what the library dependencies for various older versions of ghc are, and I don't know how to find out, short of installing several versions of ghc, upgrading their Cabal to 1.2, and guessing dependencies until it builds. Got any good hints? Regards, Malcolm
On 19/12/2007, at 9:00 PM, Malcolm Wallace wrote:
In the case of HaXml use the 1.13.3 version was updated to use the new split base libs but not to use configurations so it would also build with ghc-6.6. Hopefully we can persuade Malcolm to upload a .4 that uses configurations and works with both.
I have actually tried to use configurations for HaXml's cabal file, but I'm a bit stuck. I don't know what the library dependencies for various older versions of ghc are, and I don't know how to find out, short of installing several versions of ghc, upgrading their Cabal to 1.2, and guessing dependencies until it builds.
Got any good hints?
I don't, but I believe Bjorn does. Here's some stuff from Hope that
might help.
On 19/12/2007, at 8:44 PM, Duncan Coutts wrote:
On Wed, 2007-12-19 at 18:12 +0700, Peter Gammie wrote:
I hope that is clear. While hacking HSQL and HaskellDB I ran into this problem all the time, so I usually did clean/configure/build/haddock/ install all the time, which is no fun on one package let alone the 6 or so in that chain. Also there was no way to be sure that I'd recompiled them in the right order. For a release I expect the versioning takes care of that.
Actually, how about a command that does all that in one go? Something like:
runghc Setup buildAll <configure options>
Yes, so this is what I was talking about above, building a collection of related packages, respecting their dependencies.
Ah, I had in mind nothing so complicated. I want a one-shot command that does clean/configure/build/haddock/install/whatever else. I could write a script but I'd prefer not to. I always forget at least one of those and so things get out of sync and generally screwed up. runghc Setup DoItFromScratchAndGetOnWithIt --configure-opts As we've all had experiences with dependency tracking gone awry (ever try to build Haskell projects using 'make'? - that was fun), I suggest that some brute-force command is still very useful. I'd use this when things get screwy, not all the time. (I *always* forget to say "haddock" and wonder why I don't get any docs. Bjorn's solution is to write a Makefile :-) and the commands look something like "runghc ... clean && runghc ... build && runghc .. install" :-) Later when you have the dependency stuff, you could say: runghc Setup DoItFromScratchAndGetOnWithIt --configure-opts -- allTheDepsTooThanks and get something rebuilt from the ground up. While I'm on that topic, I'm a little worried that cabal-install is less than helpful in my case. I have a heavily hacked HSQL and HaskellDB that provides some better concurrency guarantees and data descriptions, but I've only plumbed the PostgreSQL backend. I'm sure the others are doable but I have no time or interest in doing them. So, I can't expect my far-reaching patches to be included in the main repos. This implies that if someone wants to install my stuff, they'll have to trawl my darcs repos and do a lot of it by hand. Can cabal-install be re-targeted to say "prioritise those repos over these repos", ala Debian's APT? If not, the above command would be super-useful.
This needs a proper dependencies infrastructure in Cabal, which is the next major architectural project in Cabal and is something we need more help with. Many new features are blocking on this.
That's a shame, there's already the code in GHC and hmake... I hope you can recycle it somehow. Sorry for all the armchair comments, I'm up to my eyeballs in hacking Bjorn's Hope. cheers peter
On Wed, 2007-12-19 at 22:08 +0700, Peter Gammie wrote:
Ah, I had in mind nothing so complicated. I want a one-shot command that does clean/configure/build/haddock/install/whatever else. I could write a script but I'd prefer not to. I always forget at least one of those and so things get out of sync and generally screwed up.
runghc Setup DoItFromScratchAndGetOnWithIt --configure-opts
The nearest thing is: cabal clean; cabal install --whatever-configure-options-you-like Though this does not build docs.
This implies that if someone wants to install my stuff, they'll have to trawl my darcs repos and do a lot of it by hand. Can cabal-install be re-targeted to say "prioritise those repos over these repos", ala Debian's APT? If not, the above command would be super-useful.
In principle yes, you could make some kind of repo of local unpacked build trees or remote darcs repos. It'd be a matter of teaching cabal-install how to work with such repos.
That's a shame, there's already the code in GHC and hmake... I hope you can recycle it somehow.
What we need is rather more general, though hopefully there are bits we can re-use. Duncan
participants (3)
-
Duncan Coutts -
Malcolm Wallace -
Peter Gammie