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?