ANN: Cabal 0.5 (GHC 6.4 release candidate)

This is a release-candidate for 0.6, which will be in GHC 6.4. http://www.haskell.org/cabal/download.html The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal IMPORTANT INFORMATION: See both the README file and the changelog for important interface changes. DOWNLOAD: The Haskell Cabal has reached pre-release stage. The community should use this release to evaluate the interfaces and explore the concepts of these tools. Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items to libraries@haskell.org and Isaac Jones: ijones@syntaxpolice.org. ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: You cannot currently execute the setup scripts with "./Setup.lhs" since Cabal Hugs support isn't ready-for-prime-time. You can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o setup" and then use the "setup" executable after that. This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/

Isaac Jones wrote:
This is a release-candidate for 0.6, which will be in GHC 6.4.
Thanks for the rc release. :) It would be nice if cabal allowed more choice or configuration of install directories IMHO: in particular libdir comes to mind. Also it would be nice if the default was multilib aware (eg for Fedora on x86_64 libdir is "/usr/lib64"). Personally I would like to see ghc libraries at least installed under ghc's libdir since their ABI depends on the version of ghc they are built with, ie typically under $libdir/ghc-$ghc_version/ rather than $libdir. Jens

Jens Petersen
Isaac Jones wrote:
This is a release-candidate for 0.6, which will be in GHC 6.4.
Thanks for the rc release. :)
It would be nice if cabal allowed more choice or configuration of install directories IMHO: in particular libdir comes to mind.
Do you mean more control over where the libraries themselves end up? Of course, you can use --prefix during configure, but then cabal will still put things under that prefix in a pre-determined place. You're asking for control over exactly where the libraries go?
Also it would be nice if the default was multilib aware (eg for Fedora on x86_64 libdir is "/usr/lib64").
I don't quite understand. This is for systems where you might have mixed 32 and 64 bit binaries? You want cabal to detect this situation and compile two binaries, or you would just like it to detect the default libraries location on that target?
Personally I would like to see ghc libraries at least installed under ghc's libdir since their ABI depends on the version of ghc they are built with, ie typically under $libdir/ghc-$ghc_version/ rather than $libdir.
You mean by default, without using the --prefix flag? That seems pretty reasonable. peace, isaac

Isaac Jones wrote:
Jens Petersen
writes: Isaac Jones wrote:
This is a release-candidate for 0.6, which will be in GHC 6.4.
Thanks for the rc release. :)
It would be nice if cabal allowed more choice or configuration of install directories IMHO: in particular libdir comes to mind.
Do you mean more control over where the libraries themselves end up? Of course, you can use --prefix during configure, but then cabal will still put things under that prefix in a pre-determined place. You're asking for control over exactly where the libraries go?
Also it would be nice if the default was multilib aware (eg for Fedora on x86_64 libdir is "/usr/lib64").
I don't quite understand. This is for systems where you might have mixed 32 and 64 bit binaries? You want cabal to detect this situation and compile two binaries, or you would just like it to detect the default libraries location on that target?
I'm not sure what Isaac meant, but to me it would be the ability to specify one or the other. Building two versions would be nice, but then if there were a problem with one build you might not complete the second build, which might be the one you really want. An argument to configure is the logical thing to me.
Personally I would like to see ghc libraries at least installed under ghc's libdir since their ABI depends on the version of ghc they are built with, ie typically under $libdir/ghc-$ghc_version/ rather than $libdir.
You mean by default, without using the --prefix flag? That seems pretty reasonable.
peace,
isaac _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
!DSPAM:421a2d55123166159190302!

Isaac Jones wrote:
Jens Petersen
writes: Isaac Jones wrote:
It would be nice if cabal allowed more choice or configuration of install directories IMHO: in particular libdir comes to mind.
Do you mean more control over where the libraries themselves end up? Of course, you can use --prefix during configure, but then cabal will still put things under that prefix in a pre-determined place. You're asking for control over exactly where the libraries go?
Yes, as in whether install dir is made under /usr/lib or /usr/lib/ghc-<version>/ or whatever. So really this is a request for a "--libdir" option to setup? In some cases --prefix may be sufficient, but not if there is both an executable and libraries in a package for example.
Also it would be nice if the default was multilib aware (eg for Fedora on x86_64 libdir is "/usr/lib64").
I don't quite understand. This is for systems where you might have mixed 32 and 64 bit binaries? You want cabal to detect this situation and compile two binaries, or you would just like it to detect the default libraries location on that target?
Well I'm not sure yet what the best solution is. However I mean if we're building libs with ghc.x86_64 say then they should be installed under say /usr/lib64. Well it may be too much to ask that cabal gets this completely right at this stage, but at least the "--libdir" option mentioned above would help packagers.
Personally I would like to see ghc libraries at least installed under ghc's libdir since their ABI depends on the version of ghc they are built with, ie typically under $libdir/ghc-$ghc_version/ rather than $libdir.
You mean by default, without using the --prefix flag? That seems pretty reasonable.
Yep. Actually if this were the default, I probably wouldn't need --libdir much at all. :-) Jens
participants (3)
-
Isaac Jones
-
Jens Petersen
-
Seth Kurtzberg