- cabal-devel - Haskell.org

patch applied (cabal-branches/cabal-1.2): warning police
by Duncan Coutts 24 Oct '07

24 Oct '07

Fri Sep 7 07:07:31 PDT 2007 Simon Marlow <simonmar(a)microsoft.com> * warning police M ./Distribution/Simple/GHC.hs -6 +6

1 0

patch applied (cabal-branches/cabal-1.2): Update D.S.GHC/Makefile.hs
by Duncan Coutts 24 Oct '07

24 Oct '07

Thu Sep 6 14:35:07 PDT 2007 Clemens Fruhwirth <clemens(a)endorphin.org> * Update D.S.GHC/Makefile.hs M ./Distribution/Simple/GHC/Makefile.hs -1 +1

1 0

patch applied (cabal-branches/cabal-1.2): Add shared library building to GHC module (also via Makefile)
by Duncan Coutts 24 Oct '07

24 Oct '07

Thu Sep 6 14:31:32 PDT 2007 Clemens Fruhwirth <clemens(a)endorphin.org> * Add shared library building to GHC module (also via Makefile) M ./Distribution/Simple/GHC.hs -25 +67 M ./Distribution/Simple/GHC/Makefile.in -3 +16 M ./Distribution/Simple/Install.hs -3 +1

1 0

Re: Packages within a package
by Henning Thielemann 24 Oct '07

24 Oct '07

On Tue, 23 Oct 2007, John D. Ramsdell wrote: > When I first carefully read the Cabal documentation, I remember > wondering why there is a limit of one on the number of libraries in a > package. Reflecting on autoconf, and its AC_CONFIG_SUBDIRS macro, I > also wondered why packages cannot be components of a package. If you > wrote a symbolic model checker, and you want it to be used with a > specific version of a binary decision diagram package, the simplest > way of enforcing this restriction is by including the package within > yours. This is in fact how NuSMV is distributed. (It includes CUDD.) Having sub-packages is also one thing I need, but your example is one where I think that sub-packages are the wrong approach. Uploading the imported package (the binary decision diagram one) to hackage.haskell.org and including it (in the symbolic model checker) with the concrete version number is the better way. > Recently, when I discovered there is no direct support for linking the > executables in a package with the library it defines, You can define executables in a package which are automatically build - however Cabal will recompile the imported modules instead of using the compiled ones from the library part. > I wondered why the advice was to separate the library and the > executables into two packages even though both are meant to be used and > distributed as a unit. As far as I know the future plan is to split Cabal projects into library and executable parts and then to allow also multiple library parts. This way you could provide parts for special applications or different operating systems. > Does Cabal not support things like packages within a package simply > because Haskell libraries currently are not complex enough to require > such a feature, or is there a guiding design principle with which > these features are incompatible? It was requested several times but it seems not to be designed and implemented so easily.

2 3

Re: Packages within a package
by Duncan Coutts 24 Oct '07

24 Oct '07

On Wed, 2007-10-24 at 09:03 -0400, John D. Ramsdell wrote: > Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> writes: > > > The design choice is that the Cabal package is the unit of > > distribution. Of course what one sees as a system may well consist > > of multiple interdependent packages. > > I think developers want support for developing and distributing > systems as a unit. I think I'm claiming that developers want support for developing systems as a unit but distribution can be as a collection of components rather than as a unit. Then using a package manager or cabal-install a user can pull in the components they need, including pulling in their dependencies automatically. Duncan

1 0

Re: Packages within a package
by Henning Thielemann 24 Oct '07

24 Oct '07

On Wed, 24 Oct 2007, John D. Ramsdell wrote: > Henning Thielemann <lemming(a)henning-thielemann.de> writes: > > > It was requested several times but it seems not to be designed and > > implemented so easily. > > I bet it's easier than you think. You just have to dynamically > generate package configuration files, just as I did to resolve my > linking problem. I think that this solution was already discussed. It has the drawback that I can no longer be sure what's actually in an installed package. If I have the package dependency foobar=1.0 in my Cabal file then I must be sure that foobar-1.0 on every user machine will contain all the modules in the same state as I have installed on my machine. If Cabal packages are mapped 1:1 to Debian or RPM packages then it would be really cumbersome to have to split up a project to one Cabal package per executable. Otherwise it's ok for me to handle executables in separate units ("sub-packages" or just "packages").

1 0

patch applied (cabal): Regenerate GHC/Makefile.hs from GHC/Makefile.in
by Duncan Coutts 23 Oct '07

23 Oct '07

Tue Oct 23 11:38:04 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Regenerate GHC/Makefile.hs from GHC/Makefile.in M ./Distribution/Simple/GHC/Makefile.hs -1 +1

1 0

patch applied (cabal): Only use ld -x on systems where ld supports that.
by Duncan Coutts 23 Oct '07

23 Oct '07

Tue Oct 23 11:37:38 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Only use ld -x on systems where ld supports that. Hopefully this fixes it for both ordinary builds and via ghc makefiles. M ./Distribution/Simple/GHC.hs -5 +25 M ./Distribution/Simple/GHC/Makefile.in -1 +1

1 0

Re: Patch for Haddock 2.0 support
by David Waern 23 Oct '07

23 Oct '07

> On Mon, 2007-10-22 at 01:25 +0200, David Waern wrote: >> Hi, >> >> here's the (new) patch that adds support for Haddock 2.0. > > I've applied it in Cabal HEAD. How do I test it? Install Haddock 2.0 from http://darcs.haskell.org/SoC/haddock.ghc, then run "cabal haddock" for some package. David

1 0

patch applied (cabal): pass cpp-options to cpphs
by Ross Paterson 23 Oct '07

23 Oct '07

Tue Oct 23 11:42:10 PDT 2007 Ross Paterson <ross(a)soi.city.ac.uk> * pass cpp-options to cpphs M ./Distribution/Simple/PreProcess.hs -1 +1

1 0