package description fields

[Ross Paterson]

On Tue, Aug 09, 2005 at 09:02:50AM +0100, Simon Marlow wrote:
> On 08 August 2005 16:57, Jonathan Cast wrote:
> [Simon wrote:]
> >> As far as Cabal is concerned, I think the defaults are fine. 
> >> However, I do think we should allow the default
> >> $bindir/$libdir/$datadir to be overridden (I know this has been
> >> discussed before).  On Windows, an application often finds its files
> >> relative to the location of the executable, so the values of
> >> $bindir/$libdir/$datadir need to be passed to the program at build
> >> time, perhaps via CPP symbols.  So, I suggest we have: 
> >> 
> >>   --bindir=<dir>
> >>   --libdir=<dir>
> >>   --datadir=<dir>
> >> 
> >> where the values of these would be directories relative to $prefix
> >> (or absolute?  relative to $prefix seems nicer).
> > 
> > Relative paths here break compatibility  with Autoconf; when I
> > install a program, I don't care where its configure script comes
> > from, I just want to   be  able  to   invoke  it   the  way   I 
> > expect   to.   Gratuitous incompatibilities between configure scripts
> > is very inconvenient. 
> 
> I do agree, and I half-expected someone to point out the inconsistency.
> OTOH, this isn't a "configure script", it's the Setup.lhs program.  You
> already have to know that it isn't an autoconf configure script, because
> it has different syntax.

Another incompatibility is that configure has options --datadir etc
with a different meaning to yours.  I think yours should be renamed;
we might want the autoconf-style ones too.

> One reason I suggested that relative paths would be better is because it
> allows you to build a binary/library that is prefix-independent, at
> least on Windows where a binary knows the absolute $bindir and hence can
> derive $prefix because it knows $bindir relative to $prefix.

What would the code in the packaged program look like?  It seems you'd
want some library support for this.  And what if the builder modified
bindir?