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