On Wed, 2007-10-24 at 13:08 -0400, John D. Ramsdell wrote:

Duncan Coutts 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