reason for both --libdir and --libsubdir ?

[Duncan Coutts]

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