"Setup.lhs: hope.cabal has been changed, please re-configure."

[Duncan Coutts]

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