package description fields

[Simon Marlow]

On 08 August 2005 16:57, Jonathan Cast wrote:

>> On 04 August 2005 08:24, Krasimir Angelov wrote:
>> 
>>> I would like to propose more Unix like directory layout for Windows
>>> i.e.: 
>>> 
>>> executables: %ProgramFiles%\<pkg-name>\bin
>>> libraries:       %ProgramFiles%\<pkg-name>\lib
>>> data files:     %ProgramFiles%\<pkg-name>\data
>>> 
>>> The advantage is that if you have a lot of libraries and data files
>>> then it is easier to find out the executable files.  Happy, Alex and
>>> Haddock already use layout like in the Ross's proposal but I found
>>> it very inconvenient because usually I am building them together
>>> with ghc. The problem is that when I do make install in the fptools
>>> directory then ghc is installed in ${prefix}/bin but the above tools
>>> are installed in ${prefix}. Usually then ${prefix} directory isn't
>>> included in the PATH and this makes them inaccessible. I can move
>>> them to ${prefix}/bin but then I have to move all other template
>>> files too. It would be nice if we had more consistent directory
>>> layout. 
>> 
>> Your complaint here seems to be that the default layout of Happy,
>> Alex and Haddock is different from that of GHC on Windows, which
>> makes it harder to combine all these tools in a single package.
>> 
>> 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.

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.

There's no reason we can't have both, since relative/absolute paths are
syntactically distinct.  We just say you can give a relative path, and
it is assumed to be relative to $prefix.

Isaac, shall I knock up a patch?

Cheers,
	Simon