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