On Wed, 2007-08-08 at 09:22 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
I am trying to understand the reason we have so many --dir flags to configure. I'd prefer to remove what appear to be duplicates and add some more dir overrides for specific file types (like docs).
We currently have:
--libdir= and --libsubdir= --datadir= and --datasubdir=
Hmm, I remember going through several iterations of the design here before ending up with --libsubdir. I can't remember all the rationale now (darn, wish I'd written it down somehwere). Did you check the mailing list archives?
Yes, looking back at some patch descriptions and the thread on the libraries list from Oct 2005 titled: "Cabal: bindir/libdir/datadir" the rationale becomes clearer. So the split between dir and subdir is for compatibility with autoconf, that is it allows users to say just --libdir=/usr/lib64 like they would with autoconf and end up with /usr/lib64/$pkgid/$compiler. What I was really trying to do is see if we can simplify or clarify the install paths code a bit since three people have tried and failed to add a --docdir flag thats separate from the --datadir. So I conclude that the current code is incomprehensible, perhaps because it's more complex than it needs to be or perhaps because the design just isn't documented in the code. What seems to make it complex is: * supporting prefix independence (on platforms that support it, like windows with ghc) * variable substitution * generating the Paths_pkg.hs module The logic for deciding if a package is actually relocatable isn't that obvious. It seems to be that it must be a program, not a lib and that it's bindir must be relative to $prefix. Additionally, on non-Windows, only hugs can do relocatable packages at the moment. Duncan