nice little Cabal gotcha

[Duncan Coutts]

Hi Peter,

On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote:
> Imagine this: you're hacking a library, and occasionally you put a "- 
> p" on your config line and sometimes you don't.

Yep. And Cabal doesn't track if the profiling versions of dependencies
are installed.

> (My cycle is occasional-clean-setup then build, which I grant might be  
> a bit paranoid. I get impatient and fiddle with the profiling and  
> optimisation options.)
> 
> Now, if one compiles a library with "-p", then without it, the old  
> profiling library persists in the installed location, leading to some  
> head scratching when a later compilation with a "-p" config option  
> mysteriously fails.

You mean because the old version of the profiling lib is installed but
it does not match the newer non-profiling version? So building a
dependent lib with -p fails with weird complication errors?

> Two proposals:
> 
> - rm -r $INSTALL_LOCATION (e.g. ~/lib/package/)
>   (brutal but effective; I think Cabal should claim ownership of at  
> least the package subdirs that it will populate)
> - print "Compiling normally..." and "Compiling for profiling..." to  
> make it clearer when the compilation craps out

We could easily do the latter.

> I guess you'll be squeamish about the first one,

Yep :-)

> but I for one would like such an option when hacking.

There are two ways we could do it, one is to make it possible to build
several related packages without installing them all, then we have
complete control over what is in the dist/ dir and we know when the
profiling versions of libs are out of date.

Another way is for cabal-install to gain more package management
features and remember what files belong to a package, so then we can
uninstall packages and when we replace packages we can remove all files
belonging to the existing instance of that package.

Duncan