On 21 February 2006 18:14, Einar Karttunen wrote:

On 21.02 16:50, Simon Marlow wrote:

...

I lost the argument for include files, but this is why libraries cannot currently be specified inside source files. Back in the FFI discussion, we didn't have Cabal, but now that we do, Cabal is the natural place to specify these things.

Cabal is a good place, but does not handle very well optional dependencies that most programs linking against the library don't need.

...

I don't understand this - surely if you just put those two modules in separate packages, then everything works? Or is it that you don't want to do that?

Think about a database library supporting e.g. mysql, postgresql, sqlite and odbc. Now it needs six packages to do this: 1) foo-common for common code that does not import any of the implementations 2) foo-mysql (depends on 1) 3) foo-pgsql (depends on 1) 4) foo-sqlit (depends on 1) 5) foo-odbc (depends on 1) 6) foo (this has a connect function which uses any of the above, thus depends on 1, 2, 3, 4, 5)

I don't consider this very good design and in practise this is quite tedious for the library writer.

This is exactly what you need to do. The rationale is this: for simplicity, packages are the unit in several concepts: distribution, dependency, versioning, licensing, dynamic linking, include file dependencies, external library dependencies, and more. If we start confusing the issue by having smaller units for some of these concepts, things get even more complicated. I don't think that requiring a package distinction in order to have a distinction between external library dependencies is too onerous. Packages are supposed to be lightweight things - if it is too difficult to divide a package, then we should address that in the tools and infrastructure. (I think it is more difficult than it needs to be right now, but we have been thinking about how groups of packages should look to the Cabal user recently - see discussions on the libraries list). Cheers, Simon