reason for both --libdir and --libsubdir ?
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= in each case the subdir flavour is an extra directory underneath the main dir which defaults to the package id. Seems to me that we can get rid of the subdir stuff because you can say: --libdir='/foo/bar/$pkgid/$compiler' Indeed this already works. So can we deprecate the subdir variants and tell people to just use these vars? The only thing the subdir thing was for is to be able to adjust the libdir while still getting the pkgid and compiler components generically and we can do that more flexibly with vars. Duncan
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=
in each case the subdir flavour is an extra directory underneath the main dir which defaults to the package id. Seems to me that we can get rid of the subdir stuff because you can say:
--libdir='/foo/bar/$pkgid/$compiler'
Indeed this already works. So can we deprecate the subdir variants and tell people to just use these vars?
The only thing the subdir thing was for is to be able to adjust the libdir while still getting the pkgid and compiler components generically and we can do that more flexibly with vars.
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? Cheers, Simon
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
On Wed, 2007-08-08 at 12:06 +0100, Duncan Coutts wrote:
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.
Just for reference here's autoconf's full list (it's big): --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/gtk2hs] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] See also: http://www.gnu.org/software/autoconf/manual/html_node/Installation-Directory... http://www.gnu.org/software/autoconf/manual/standards/Directory-Variables.ht... They have some historical cruft we can ignore, like the --datarootdir and --oldincludedir. Note that the default autoconf docdir includes the package name. Additionally, automake supports installing files into any of these with an additional packagename subdir.
participants (2)
-
Duncan Coutts -
Simon Marlow