Packages within a package

[Henning Thielemann]

On Tue, 23 Oct 2007, John D. Ramsdell wrote:

> When I first carefully read the Cabal documentation, I remember
> wondering why there is a limit of one on the number of libraries in a
> package.  Reflecting on autoconf, and its AC_CONFIG_SUBDIRS macro, I
> also wondered why packages cannot be components of a package.  If you
> wrote a symbolic model checker, and you want it to be used with a
> specific version of a binary decision diagram package, the simplest
> way of enforcing this restriction is by including the package within
> yours.  This is in fact how NuSMV is distributed.  (It includes CUDD.)

Having sub-packages is also one thing I need, but your example is one
where I think that sub-packages are the wrong approach. Uploading the
imported package (the binary decision diagram one) to hackage.haskell.org
and including it (in the symbolic model checker) with the concrete version
number is the better way.

> Recently, when I discovered there is no direct support for linking the
> executables in a package with the library it defines,

You can define executables in a package which are automatically build -
however Cabal will recompile the imported modules instead of using the
compiled ones from the library part.

> I wondered why the advice was to separate the library and the
> executables into two packages even though both are meant to be used and
> distributed as a unit.

As far as I know the future plan is to split Cabal projects into library
and executable parts and then to allow also multiple library parts. This
way you could provide parts for special applications or different
operating systems.

> Does Cabal not support things like packages within a package simply
> because Haskell libraries currently are not complex enough to require
> such a feature, or is there a guiding design principle with which
> these features are incompatible?

It was requested several times but it seems not to be designed and
implemented so easily.