simonmar at microsoft.com
Thu Oct 6 07:29:54 EDT 2005
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
>> 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
> Is there a reason not to use
> by default, thus making it easy to give either relative or absolute
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.
More information about the Libraries