package description fields

[Jonathan Cast]

> 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.

Jon Cast