What are best practices for managing related Cabal packages?

Posted by Norman Ramsey on Stack Overflow See other posts from Stack Overflow or by Norman Ramsey
Published on 2010-04-13T02:37:46Z Indexed on 2010/04/13 2:43 UTC
Read the original article Hit count: 432

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?

© Stack Overflow or respective owner

Related posts about best-practices

Related posts about cabal