What are best practices for managing related Cabal packages?

Question

I'm working on a dataflow-based optimization library written in Haskell. It now seems likely that the library is going to have to be split into two pieces:

• A core piece with minimal build dependencies; call it hoopl-core.

• A full piece, call it hoopl, which may have extra dependencies on packages like a prettyprinter, QuickCheck, and so on.

The idea is that the Glasgow Haskell Compiler will depend only on hoopl-core, so that it won't be too difficult to bootstrap the compiler. Other compilers will get the extra goodies in hoopl. Package hoopl will depend on hoopl-core.

The Debian package tools can build multiple packages from a single source tree. Unfortunately Cabal has not yet reached that level of sophistication. But there must be other library or application designers out there who have similar issues (e.g., one package for a core library, another for a command-line interface, another for a GUI interface).

What are current best practices for building and managing multiple related Haskell packages using Cabal?

Answer 1

Put the two packages into separate subdirectories of your source control repo, and use two separate cabal files.

Make sure you use the move operation of your source control system when moving files, so that it tracks the history properly.

Answer 2

I'd put the two packages in separate subdirectories, and have a Makefile with something like this:

.PHONY: all hoopl hoop-core
all : hoopl

hoopl : hoopl-core
       cd hoopl && cabal build && cabal register --inplace

hoopl-core
       cd hoopl-core && cabal build && cabal register --inplace

this assumes you've bootstrapped the process by first building hoopl-core and registering it (--inplace) and then building hoopl. You could automate more of this using the Makefile.

As you know, when we wanted similar functionality for GHC, we wrote our own build system instead ;-) I don't recommend that. Technically I suppose it would be possible to extract from the GHC build system the required pieces and make a re-usable framework, though...