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
_______________________________________________
cabal-devel mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cabal-devel
