datadir (was: RE: new package description fields, sdist, and preprocessors)

[Simon Marlow]

On 09 August 2005 02:59, Isaac Jones wrote:

> Ross Paterson <ross at soi.city.ac.uk> writes:
>> On Wed, Aug 03, 2005 at 07:27:01PM -0500, Brian Smith wrote:
>>> On 8/3/05, Ross Paterson <ross at soi.city.ac.uk> wrote:
>>>> 3) New field data-files, a list of files to be copied to a place
>>>>    where an executable can find them (e.g. template-hsc.h for
>>>>         hsc2hs): Hugs: the directory containing the Main module
>>>>         GHC/Windows: the directory containing the executable
>>>>         GHC/Unix: /usr/local/share/<exename>
>>>>    plus a new function in System.Directory to return the name of
>>>>    this directory.  That would address Dimitry's requirements in
>>> 
>>> How about allowing directories too, which would be copied
>>> recursively? 
>> 
>> No objection to that.
> 
> This sounds good, except that I'm not sure that System.Directory is
> the right place for this.  It could also go in Distribution
> somewhere, but either way may be fine.
> 
> Also, if we do this, we should probably specify the manner in which
> such a directory should be layed out so:
> 
> 1) it doesn't get too cluttered
> 2) different packages don't stomp on each-other's files and
> 3) different versions of different packages can use the same
> filenames. 
> 
> One stab at it (where dataFileDir :: FilePath) would be that your
> datafiles should be in:
> 
> System.Directory.dataFileDir
>   `joinFilePath` (packageName ++ "-" packageVersion)
> 
> and this is where cabal will put it.

This overlaps with my --datadir proposal.  I think that datadir should
be configurable at Setup-time, with sensible defaults as per Ross's mail
above.  The default should at least be specified relative to $prefix
(eg. if $prefix is /usr, I don't want $datadir to be
/usr/local/share/<pkg>).  Also, if the data files are machine-dependent
then they should really go in $libdir rather than $datadir.

The problem, of course, is how to get the value of $datadir to the
program if it is configurable.  I suggested a CPP symbol, but that is
far from ideal (we don't do it this way in fptools projects any more for
various reasons).  Another option is to have the Setup script generate a
file containing the declarations:

-- paths.h
prefix="/usr/local"
bindir="bin" -- or absolute
libdir="lib/foo-1.0/ghc-6.4"
datadir="share/foo-1.0"

which you can then #include into Haskell source.  Another alternative,
if you want to avoid CPP, is to have Setup generate a complete Haskell
module with these declarations, but then you have to somehow choose an
appropriate module name that doesn't clash.

paths.h gets my vote.  Anyone have any better ideas?

Cheers,
	Simon