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