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