| I started off from the assumption that "shipments" are necessary and | obviously beneficial. However after thinking about it for a while and | thinking through some of the implications (especially on dependency | resolution) I'm not not so convinced that we need shipments as such. I have not been following this thread much, but my original understanding was precisely that A Cabal package *is* the unit of distribution Indeed, that's what it is for I'm entirely unclear why new need some other larger unit. Yes, a Cabal package may depend on other Cabal package, but those dependencies are explicit in the package descr file, and Cabal-get can follow the links. Any larger unit (shipments) will also have dependencies that need to be followed, in just the same way, so I don't understand what has been gained. I'm probably missing something, but perhaps someone can write down the reasoning on Duncan's Wiki page? http://haskell.org/hawiki/Cabal_2fMultiPackageDistributables Simon
Cabal already supports multiple executables in one package but only
one library.
The problem is that the current implementation is just a hack. The
shipment allows to pack multiple packages in one tar.gz file and to
build them together. Each package will have only one library or only
one executable and this resumes the symmetry between executables and
libraries. I found that this simplifies the code a lot.
Cheers,
Krasimir
2005/12/9, Simon Peyton-Jones
| I started off from the assumption that "shipments" are necessary and | obviously beneficial. However after thinking about it for a while and | thinking through some of the implications (especially on dependency | resolution) I'm not not so convinced that we need shipments as such.
I have not been following this thread much, but my original understanding was precisely that
A Cabal package *is* the unit of distribution Indeed, that's what it is for
I'm entirely unclear why new need some other larger unit. Yes, a Cabal package may depend on other Cabal package, but those dependencies are explicit in the package descr file, and Cabal-get can follow the links. Any larger unit (shipments) will also have dependencies that need to be followed, in just the same way, so I don't understand what has been gained.
I'm probably missing something, but perhaps someone can write down the reasoning on Duncan's Wiki page? http://haskell.org/hawiki/Cabal_2fMultiPackageDistributables
Simon
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
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
participants (3)
-
Duncan Coutts -
Krasimir Angelov -
Simon Peyton-Jones