Cabal: bindir/libdir/datadir

[Simon Marlow]

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