Packages within a package

[Duncan Coutts]

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?

No.

> Maybe Cabal should do just one thing, and one thing well, package
> components of systems into the smallest units available for
> distribution.
> 
> 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
dependency.

> 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:
./configure
make
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:
cabal configure
cabal build
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.

Duncan