package description fields

[Simon Marlow]

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).  And when processing with
CPP, Cabal would pass -DBINDIR=<dir> -DLIBDIR=<dir> -DDATADIR=<dir>.

Using this, Krasimir could configure Happy, Alex and Haddock to use a
layout compatible with GHC, whereas the defaults would reamin as they
are.

Cheers,
	Simon