nice little Cabal gotcha
duncan.coutts at worc.ox.ac.uk
Sun Apr 13 19:36:06 EDT 2008
On Thu, 2008-04-10 at 11:29 +0700, Peter Gammie wrote:
> On 10/04/2008, at 3:57 AM, Duncan Coutts wrote:
> > 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?
> Just to clarify slightly: "install" is just additive, so any old cruft
> in the install directories persists if not overwritten. If the package
> interface hasn't changed, the later "-p" compilation of something else
> may succeed, but misbehave relative to expectations.
Ah, so same interface but changed semantics.
> My proposal is that if cabal is going to install something in, e.g.:
> that it say:
> rm -rf ~/lib/package/ghc-6.6.1/*
> first. Surely it is reasonable to say Cabal "owns" that particular
I don't think so, no.
> I also feel the same way about documentation.
> Now tracking dependencies a partial solution to this: imagine I remove
> a module from my .cabal file, then "clean" "build" "install". Will
> Cabal delete the removed-module's .hi (etc.) file?
> Can you expand on your squeamishness?
We should not delete files we don't know that we own. We only know we
own files we're installing. So we cannot delete anything.
Only a package manager can do that because it knows what files belong to
the package we're replacing. Of course cabal-install is a package
manager of sorts so if it tracked what files belonged to packages it
installed then it'd know what files to remove when it replaced packages.
> I can feel a proposal for a "--force" relative coming on, something
> like "--purge-old-crap". :-)
The other problem is that we do not necessarily install all files into
one directory. In fact it's not even the default on unix. The various
different kinds of files go in different dirs and the user can change
any of them.
> I'll write up a ticket after your response.
Perhaps I can convince you that the better solution is to get Cabal to
provide a way track installed files and for cabal-install to actually do
More information about the cabal-devel