- Libraries - Haskell.org

cabal question / feature request
by Johannes Waldmann 10 Oct '05

10 Oct '05

Dear all. is there a way to get the preprocessed sources of a project from Cabal? Is this what "Setup copy" is for? (I guess not.) If I do "runhaskell Setup.hs sdist", I get a tarball with the original sources (macros not expanded). If I do "runhaskell Setup.hs haddock" it seems the preprocessed sources are built - but then deleted, so I only get what haddock makes of them (and this I don't like - I need more control over haddock options, so I need to run it outside cabal.) Can I get the desired effect by doing Setup configure for hugs and then Setup install? (Would this install preprocessed sources?) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

Cabal: versioning of the hooks API
by Simon Marlow 10 Oct '05

10 Oct '05

Folks, I've made some changes that affect the hooks API. It occurs to me that changes in this API will automatically break any Cabal Setup.lhs that is using the old API, and there isn't a good workaround, since when you say 'runhaskell Setup.lhs' you're at the mercy of whatever packages are visible to the default compiler. I wonder, should we explicitly version this API? That is, should we provide defaultMainWithHooks2, defaultMainWithHooks3...? That would at allow us some backwards compatibility, and make things break earlier and more predictably if the required version of Cabal isn't available. On the down side, it requires us to support multiple versions of the API simultaneously. We could use DEPRECATED pragmas to encourage people to update their Setup.lhs scripts. Thouhts? Cheers, Simon

1 0

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 10 Oct '05

10 Oct '05

On 07 October 2005 13:06, Ross Paterson wrote: > On Fri, Oct 07, 2005 at 01:05:04PM +0100, Ross Paterson wrote: >> On Fri, Oct 07, 2005 at 12:35:21PM +0100, Simon Marlow wrote: >>> Paths.hs-inc is auto-generated, and contains >>> >>> getBinDir :: IO FilePath >>> getLibDir :: IO FilePath >>> getDataDir :: IO FilePath >>> getLibexecDir :: IO FilePath >> >> Does this have to be #include'd, or could it be a module? > > Oops, forget I said that. Paths.hs-inc is a pain, but the problem with making it a module is that you have to pick a non-conflicting module name, as I'm sure you realised. So how about incorporating the package name into the module name, to avoid the conflict - eg. import Paths_alex? or Cabal.Paths_alex? Cheers, Simon

1 0

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 07 Oct '05

07 Oct '05

On 07 October 2005 12:08, Ross Paterson wrote: >> So we could actually make $libextradir visible and explicit, i.e. >> change the scheme to this: >> >> libdirrel = lib (by default) >> libextradir = $package/$compiler >> libInstDir = $prefix/$libdirrel/$libextradir >> >> Is that what you want? > > Yes, setting libdirrel independently from libextradir gives > interoperability with autoconf, and also means installers don't have > to mess with Cabal's placement policy unless they really want to. > One could specify libdirrel with a new option or with --libdir > (possibly extended with substitutions). Ok, so I take it you'd prefer --libdir instead of --libdirrel. We can do that, but (a) we have to change --copy-prefix and (b) we have to give an error on Windows if you use --libdir to specify a path that doesn't begin with $prefix, at least for an executable. Both of these are fine by me. So, here's the plan. options to ./setup configure: --prefix=<dir> --libdir=<dir> --libsubdir=<dir> --datadir=<dir> --datasubdir=<dir> --bindir=<dir> --libexecdir=<dir> where <dir> can include $(prefix), $(package), $(compiler). libs are installed in $libdir/$libsubdir. Paths.hs-inc is auto-generated, and contains getBinDir :: IO FilePath getLibDir :: IO FilePath getDataDir :: IO FilePath getLibexecDir :: IO FilePath Executables on Windows are prefix-independent, the above functions assume they are being called by a binary in $bindir. On Unix, and for libraries on Windows, the above functions all return fixed values. On Windows, specifying any --*dir value which does not begin with $(prefix) for an executable elicits an error. I'm still not quite sure how to implement this, because the Windows version of the code is non-trival and requires a bunch of imports & flags. Additionally, we add --copy-root=<dir> with the old meaning of --copy-prefix, and deprecate --copy-prefix (or just change --copy-prefix back again?). Cheers, Simon

2 2

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 07 Oct '05

07 Oct '05

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

2 1

Cabal: bindir/libdir/datadir
by Simon Marlow 07 Oct '05

07 Oct '05

While I was away last week I hacked into Cabal support for bindir/libdir/datadir, as previously discussed on this list. However, while doing it I changed my mind about the design so thought I'd run it past the list. The problem with bindir/libdir/datadir is that they are specified as absolute pathnames, but in reality most of the time they will be relative to (i.e. subdirectories of) prefix. Specifying them with absolute pathnames is inconvenient because: - The "setup copy" command already has --copy-prefix, and it would need additional arguments --copy-bindir, --copy-libdir etc. if bindir and friends were absoluate paths (actually, I don't know why we have --copy-prefix, when we should really have a --copy-to that is prepended to the existing prefix, that would eliminate the need for --copy-bindir etc.). - On Windows and systems that support querying the pathname of a running binary, we want to support prefix-independent installs, such that a binary can find its files by only knowing the directory layout under $prefix, not the value of prefix itself. If bindir/libdir/datadir are relative to prefix, we can do this. However, specifying bindir/libdir/datadir with absolute pathnames is desirable because: + It's what autoconf does + If the Cabal package is implemented using autoconf+make, then --bindir can be passed direct to ./configure (but implementing the appropriate impedence matching for relative paths isn't hard either). In the end I plumped for relative pathnames, but I renamed the options: --bindirrel=<dir> --libdirrel=<dir> --datadirrel=<dir> --libexecdirrel=<dir> 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. With these changes I've Cabalised Alex (Happy & Haddock to follow). Please shout if you object to the design in any way. I plan to write a section for the documentation describing all this. 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? We might also want a simple way in the .cabal file to specify some files to be installed in $datadir (I think someone suggested this before). It's quite annoying to do it with hooks. Cheers, Simon

4 4

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 07 Oct '05

07 Oct '05

On 06 October 2005 18:46, Krasimir Angelov wrote: > 2005/10/6, Simon Marlow <simonmar(a)microsoft.com>: >> --bindirrel=<dir> >> --libdirrel=<dir> >> --datadirrel=<dir> >> --libexecdirrel=<dir> > > bindirrel, libdirrel, ... looks a little bit verbose. Why not just > bindir/libdir? Because bindir/libdir are already used by autoconf with a different meaning. >> 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) Yes, in fact it is: getDataDir :: IO FilePath getDataDir = do mb_path <- getPrefix binDirRel return (fromMaybe prefix mb_path `joinFileName` dataDirRel) > I think that is better to add these templates to Paths.hs-inc. Fine by me. One problem is that I need to use stuff from Distribution.Compat.FilePath, which isn't available outside Cabal, and in any case we don't want every package to depend on Cabal. I might have to include a definition of joinFileName in Paths.hs-inc too. > 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. A library cannot be prefix-independent, only an executable. That was the assumption I was working with, sorry for not making it clear. > 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> That's sounds like a reasonable default. The current defaults for a library on Windows are: prefix = C:\Program Files\ bindirrel = $package libdirrel = Haskell\$package\$compiler datadirrel = $package libexecdirrel = $package you suggest changing datadirrel to: datadirrel = Common Files\$package and on Unix, for completeness: prefix = /usr/local bindirrel = bin libdirrel = lib/$package/$compiler datadirrel = share/$package libexecdirrel = libexec > 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. No, I think we want datadir to be relative to prefix. It should be possible to install a library in your home directory, for example. Cheers, Simon

2 1

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 06 Oct '05

06 Oct '05

On 06 October 2005 12:25, Ross Paterson wrote: > On Thu, Oct 06, 2005 at 11:29:30AM +0100, Simon Marlow wrote: >> - The "setup copy" command already has --copy-prefix, and it would >> need additional arguments --copy-bindir, --copy-libdir etc. if >> bindir and friends were absoluate paths (actually, I don't know >> why we have --copy-prefix, when we should really have a >> --copy-to that is prepended to the existing prefix, that would >> eliminate the need for --copy-bindir etc.). > > We did have that for a while, but someone objected to it: > http://www.haskell.org//pipermail/cvs-libraries/2005-January/003175.html Heh :-) Thanks Ross. Well, I wasn't taking into account absolute bindir/libdir. It's not a big deal, as long as we don't have absolute bindir/libdir paths there's no need to change it back. Cheers, Simon

1 0

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 06 Oct '05

06 Oct '05

On 06 October 2005 11:43, Ian Lynagh wrote: > On Thu, Oct 06, 2005 at 11:29:30AM +0100, Simon Marlow wrote: >> While I was away last week I hacked into Cabal support for >> bindir/libdir/datadir, as previously discussed on this list. >> However, while doing it I changed my mind about the design so >> thought I'd run it past the list. >> >> The problem with bindir/libdir/datadir is that they are specified as >> absolute pathnames, but in reality most of the time they will be >> relative to (i.e. subdirectories of) prefix. [...] >> In the end I plumped for relative pathnames, but I renamed the >> options: >> >> --bindirrel=<dir> >> --libdirrel=<dir> >> --datadirrel=<dir> >> --libexecdirrel=<dir> > [...] >> 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? > > Is there a reason not to use > > --libdir=%prefix/lib/%package/%compiler/ > > by default, thus making it easy to give either relative or absolute > paths? If we allow absolute paths for --libdir, then two problems arise: the builder can break prefix-independent installs on Windows, and it means we need a --copy-libdir family of options (or change --copy-prefix, as per my previous message). I realise being different here will mean that people react with "why the hell did they have to deviate from autoconf?". But autoconf is a bit Unix-centric here, which turns out to be problematic. Using relative pathnames is technically better. Cheers, Simon

1 0

How to fix aclocal.m4 of OpenAL Library to works well Windows and Mac OS X platform?
by shelarcy 26 Sep '05

26 Sep '05

Hello. I'm trying to build OpenAL Library on Windows and Mac OS X. I have already done about OpenAL/configure.ac and OpenAL/Sound/OpenAL/Config.hs, but I don't know about how to fix OpenAL/aclocal.m4's FP_FUNC_ALCPROCESSCONTEXT_VOID and FP_FUNC_ALCDESTROYCONTEXT_VOID. These funcation doesn't works well on at least Windows and Mac OS X platform, so ALCPROCESSCONTEXT_VOID and ALCDESTROYCONTEXT_VOID isn't defined on there platforms. Does anyone has idea? -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

2 2