- Libraries - Haskell.org

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

RE: Unexpected behaviour in Text.PrettyPrint.HughesPJ
by Simon Peyton-Jones 23 Sep '05

23 Sep '05

That does seem like a bug to me. I would love it if someone else could dig into the library and fix it.... it's years since I looked at it. Probably there are many things that could be improved. I have no ego investment in it, so it's 100% open to improvement. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Anders | Höckersten | Sent: 22 September 2005 07:42 | To: Haskell libraries | Subject: Unexpected behaviour in Text.PrettyPrint.HughesPJ | | Hi, | I've been using the pretty printer in Text.PrettyPrint.HughesPJ lately, | and I've encountered a behaviour that was very unexpected for me. If I | define this small example: | | test = text "foo" <+> empty <> text "bar" | | Running 'show test' now gives the string "foobar" as a result (whereas I | expected "foo bar").It seems the empty "eats" the space that I expect | <+> to give me. | | So is this how the library is supposed to work or have I encountered a | bug? | | Regards, | Anders | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

5 4

RE: cabal beginner issues (other-modules, build-depends)
by Simon Marlow 23 Sep '05

23 Sep '05

On 23 September 2005 10:47, Ross Paterson wrote: > On Fri, Sep 23, 2005 at 10:37:52AM +0100, Simon Marlow wrote: >> On 23 September 2005 10:20, Ross Paterson wrote: >>> Module dependency calculation would have to be done in the build >>> environment, not at the source, because the set of modules used may >>> be system-dependent. And you'd still need to specify >>> exposed-modules. >> >> Yes, that's what I had in mind. The calculation of other-modules >> would happen when .installed-pkg-info is generated. > > I forgot extra-source-files, which is needed in the source system and > has to include all the files not mentioned elsewhere that might be > needed > on any build system. Without other-modules you'd need it more often, > and it would be harder to compute. So let's do the second best thing, and automatically check the value of the other-modules field if appropriate tools are available (GHC or hmake). Cheers, Simon

1 0

RE: Unexpected behaviour in Text.PrettyPrint.HughesPJ
by Simon Peyton-Jones 23 Sep '05

23 Sep '05

Ah yes -- a better answer than mine. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Johannes | Waldmann | Sent: 23 September 2005 09:55 | To: Simon Peyton-Jones | Cc: Haskell libraries | Subject: Re: Unexpected behaviour in Text.PrettyPrint.HughesPJ | | | > | test = text "foo" <+> empty <> text "bar" | > | | > | Running 'show test' now gives the string "foobar" as a result (whereas I | > | expected "foo bar").It seems the empty "eats" the space that I expect | > | <+> to give me. | | by definition, x <+> empty == x. | | what happens here is related to precedences: | | Text.PrettyPrint.HughesPJ> text "foo" <+> empty <> text "bar" | foobar | Text.PrettyPrint.HughesPJ> text "foo" <+> ( empty <> text "bar" ) | foo bar | | best regards, | -- | -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- | ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0