Shipments in Cabal

[Duncan Coutts]

On Fri, 2005-12-09 at 10:42 +0200, Krasimir Angelov wrote:
> Cabal already supports multiple executables in one package but only
> one library.

I think that's because we track dependencies on libraries but not
executables. So having one lib per package allows us to track library
deps correctly.

Having more than one library in a package breaks dependency checking as
described in the wiki page.

If a shipment is merely an aggregation of cabal packages and the package
remains the dependency tracking unit then it's ok.

However a key point is this:

You must be able to build the individual packages within a shipment
separately (though respecting their dependencies). We do not want to end
up in the situation where to build another optional package from a
shipment you have to rebuild every other dependant package in that
shipment.

As an example, suppose Gtk2Hs is a shipment with 2 large core packages
and 6 small optional ones. If to satisfy a dependency you need to
install one of the extra optional packages but you've already got the
core packages installed then you really do not want to have to rebuild
those core packages (which take 10 times longer to build than any of the
optional packages).

The danger of a shipment as opposed to merely a collection of cabal
packages (with deps between them) is that there can be hidden
dependencies. If they are all built together then people will be tempted
to communicate information from one build to another within the build
tree, for example by sharing the results of ./configure or by picking
up .chi files from another package. All these things would break if we
try to build the packages in a shipment separately (which is exactly
what cabal-get and other package managers will want to do).

It would certainly be useful to have a way of managing and building a
collection of related packages but I'm not sure that there is any
benefit on the users end.

For example a developer will want an easy way of building a project that
consists of several packages and many of those package might share the
same information (eg version number, copyright, homepage etc).

However is there any reason for that collection of packages to be
distributed to end users in one tarball and built together in one build
tree, rather than just using the dependency resolution mechanism of
cabal-get or the system package manager?

Duncan