Cabal: bindir/libdir/datadir

[Simon Marlow]

On 07 October 2005 10:07, Ross Paterson wrote:

> On Thu, Oct 06, 2005 at 11:29:30AM +0100, Simon Marlow wrote:
>> [...]
>> How can the package itself find out what these paths are?  As
>> discussed previously, Cabal generates a file Paths.hs-inc containing
>> 
>>    prefix = "<dir>"
>>    binDirRel = "<dir>"
>>    libDirRel = "<dir>"
>>    ... etc ...
>> 
>> which can be #included into Haskell source.  Additionally I have the
>> function: 
>> 
>>    getPrefix :: FilePath{-binDirRel-} -> IO (Maybe FilePath)
>> 
>> which figures out prefix when called from a binary installed in
>> $prefix/$bindirrel.  If it returns Nothing, then you can fall back to
>> the hard-coded value of prefix from Paths.hs-inc.
> 
> Can you show the client code to find data files under any system and
> compiler?

Ok, here's what I use in Alex:

#include "Paths.hs-inc"
getDataDir :: IO FilePath
getDataDir = do 
  m <- getPrefix binDirRel
  return (fromMaybe prefix m `joinFileName` dataDirRel)

getPrefix :: FilePath -> IO (Maybe FilePath)
  -- always returns Nothing on Unix, on Windows calculates
  -- prefix from the path of the executable, assuming the current
  -- executable is in $prefix/$bindirrel.

This code is always the same, so as Krasimir pointed out we should
provide it to the executable via Paths.hs-inc somehow.  Good ideas for
how to do this are welcome.

>> There's one thing I'm not sure about yet: the default $libdirrel on
>> Unix systems is lib/<pkgid>/<compiler>, eg. lib/pkg-0.2/ghc-6.4, and
>> you might want to change just the "lib" bit, eg. to get
>> lib64/pkg-0.2/ghc-6.4.  It's annoying to have to specify the <pkgid>
>> and <compiler> when Cabal knows them, so we might want a simple
>> substitution syntax, such as --libdirrel=lib64/%p/%c.  Sound
>> reasonable? 
> 
> There's a difference between the package libdir's you're talking about
> (e.g. $prefix/lib/$PackageId/$CompilerId) and --libdir in autoconf
> (default $prefix/lib).  You couldn't easily generate the options to
> configure from *dirrel.  But do we really need an option to specify
> the package libdir, or just --libdir (in the autoconf sense)? 
> "lib64/%p/%c" is easier than the full thing, but it still exposes
> Cabal's placement policy to lots of installers.  Similarly bindir,
> datadir, libexecdir and maybe includedir.  There would be no problem
> with generalizing the autoconf options, though, say to allow
> substitutions (e.g. of prefix). 

Hmm.  *scratches head*  *gets coffee*

We have slightly different views on the world, I think.  I'm going to
try to describe both, so that at least I can understand what's going on.

So there's a directory I'll call libInstDir, where the libraries for a
package actually get installed.  In my scheme, libInstDir is constructed
like this:

  libdirrel  = lib/$package/$compiler  (by defualt)
  libInstDir = $prefix/$libdirrel

in your view of the world, it is constructed like this:

  libdir      = $prefix/lib		   (by default)
  libextradir = $package/$compiler
  libInstDir  = $libdir/$libextradir

so there's an extra layer, namely the "$package/$compiler" that gets
added by the build system (or something) when installing libraries.
(GHC does this, and I don't like it much).

The actual value of libInstDir needs to be visible to the
program/library, especially for dataInstDir, which is why perhaps having
the hidden $libextradir layer is not so good.  Also it's desirable to
have the whole of libInstDir configurable.

So we could actually make $libextradir visible and explicit, i.e. change
the scheme to this:

  libdirrel   = lib (by defualt)
  libextradir = $package/$compiler
  libInstDir  = $prefix/$libdirrel/$libextradir

Is that what you want?

Cheers,
	Simon