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

Peter Gammie peteg42 at gmail.com
Wed Dec 19 10:08:11 EST 2007


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



More information about the cabal-devel mailing list