package description fields
ross at soi.city.ac.uk
Tue Aug 9 06:23:13 EDT 2005
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
More information about the Libraries