Cabal: bindir/libdir/datadir

[Krasimir Angelov]

2005/10/6, Simon Marlow <simonmar at microsoft.com>:
>   --bindirrel=<dir>
>   --libdirrel=<dir>
>   --datadirrel=<dir>
>   --libexecdirrel=<dir>

bindirrel, libdirrel, ... looks a little bit verbose. Why not just
bindir/libdir?

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

What does the argument of getPrefix mean? Is it the --bindirrel value?
With this semantic I should write something like this each time:

getDataDir :: IO FilePath
getDataDir = do
  mb_path <- getPrefix bindir
  case mb_path of
     Just path -> return (path ++ datadir)
     Nothing   -> return (prefix ++ datadir)

I think that is better to add these templates to Paths.hs-inc. The
prefix constant doesn't make sense under Windows. The program
shouldn't assume that it is installed at any specific place.
Paths.hs-inc should contain: getBinDir, getLibDir and getDataDir
functions where under Unix they should return any hard coded value
while under Windows they should compute the real value.

I am worried about the meaning of these directories for the library
packages. Under Unix the getDataDir will return any constant value, so
that all executables which are linked to the given library will share
the same data files. Under Windows if datadir is relative to the
executable directory then each application will need its own copy of
the shared files. It is even tricky to compute datadir for libraries
under Windows. There will be two getDataDir functions. One in the
Paths.hs-inc for the library and second for the executable to which
the library is linked. The getDataDir in the library should know the
bindir value specified for the executable in order to work properly.
Instead of this I think that the right place for the library specific
data files is:

C:\Program Files\Common Files\<package>

This might sense for Unix too. For some libraries it might be prefered
to use /etc/<package>, so the datadir isn't necessary relative to the
prefix.

Cheers,
  Krasimir