Packages within a package
duncan.coutts at worc.ox.ac.uk
Wed Oct 24 14:19:23 EDT 2007
On Wed, 2007-10-24 at 13:08 -0400, John D. Ramsdell wrote:
> Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:
> > 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.
> Do you believe it is a bad idea to expect that Cabal be the
> appropriate tool for developing systems as a unit?
> Maybe Cabal should do just one thing, and one thing well, package
> components of systems into the smallest units available for
> I had been thinking of Cabal as a development tool as well as a
> packaging tool, similar to autoconf/automake, but perhaps Cabal is
> really meant to be similar to rpmbuild and dpkg-buildpackage. Maybe
> thinking of it as a development tool was an error on my part.
Currently it only helps with a single package at a time, so dealing with
multi-package systems is cumbersome. The intention is to extend it to
help developers working with multi-package systems.
My claim is that all that requires is improvements in the tools, not a
change in the notion of a package as the unit of distribution and
> For my application, I suppose I could use autoconf/automake to develop
> the software, install the executables, build a Cabal package
> description, and then use it with Cabal to make the library available
> as a package. Is this usage more inline with your intentions?
We'd like to kill off autoconf as much as possible. :-)
So we hope that developers will work directly with Cabal rather than
generating Cabal packages from other systems.
As I said before, my personal example is Gtk2Hs which is a relatively
complex multi-package system. Currently it is impossible to package it
with Cabal but we're getting closer. Gtk2Hs currently uses
autoconf/automake and I can build everything with:
and I can rebuild everything with just make. And if there's nothing to
do it takes a fraction of a second to work this out. I'd like to get to
that stage with cabal. I'd like to say:
Or maybe just cabal build to get default configure parameters. And if I
run cabal sdist I'd expect it to generate twelve .tar.gz packages that I
can upload to hackage.
With that kind of infrastructure there's lots of fun stuff we could do,
like continuous build and test:
cabal build --continuous &
To get there of course we'll need lots of help from lots of people. I'd
like to encourage people to get involved.
More information about the cabal-devel