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