What are best practices for managing related Cabal packages?
- by Norman Ramsey
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?
