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

[Peter Gammie]

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