2005/10/6, Simon Marlow
--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