On 06 October 2005 11:43, Ian Lynagh wrote:
On Thu, Oct 06, 2005 at 11:29:30AM +0100, Simon Marlow wrote:
While I was away last week I hacked into Cabal support for bindir/libdir/datadir, as previously discussed on this list. However, while doing it I changed my mind about the design so thought I'd run it past the list.
The problem with bindir/libdir/datadir is that they are specified as absolute pathnames, but in reality most of the time they will be relative to (i.e. subdirectories of) prefix. [...] In the end I plumped for relative pathnames, but I renamed the options:
--bindirrel=<dir> --libdirrel=<dir> --datadirrel=<dir> --libexecdirrel=<dir> [...] There's one thing I'm not sure about yet: the default $libdirrel on Unix systems is lib/<pkgid>/<compiler>, eg. lib/pkg-0.2/ghc-6.4, and you might want to change just the "lib" bit, eg. to get lib64/pkg-0.2/ghc-6.4. It's annoying to have to specify the <pkgid> and <compiler> when Cabal knows them, so we might want a simple substitution syntax, such as --libdirrel=lib64/%p/%c. Sound reasonable?
Is there a reason not to use
--libdir=%prefix/lib/%package/%compiler/
by default, thus making it easy to give either relative or absolute paths?
If we allow absolute paths for --libdir, then two problems arise: the builder can break prefix-independent installs on Windows, and it means we need a --copy-libdir family of options (or change --copy-prefix, as per my previous message). I realise being different here will mean that people react with "why the hell did they have to deviate from autoconf?". But autoconf is a bit Unix-centric here, which turns out to be problematic. Using relative pathnames is technically better. Cheers, Simon