我正在研究用Haskell编写的基于数据流的优化库。现在看来，图书馆可能需要分成两部分：
具有最小构建依赖性的核心部分;称之为hoopl-core。
一个完整的部分，称之为hoopl，它可能对诸如prettyprinter，QuickCheck等软件包有额外的依赖关系。
我们的想法是格拉斯哥Haskell编译器只依赖于hoopl-core，因此引导编译器不会太困难。其他编译器将在hoopl中获得额外的好处。套餐hoopl取决于hoopl-core。
Debian软件包工具可以从单个源树构建多个软件包。不幸的是Cabal has not yet reached that level of sophistication。但是必须有其他具有类似问题的库或应用程序设计者（例如，一个用于核心库的包，另一个用于命令行界面，另一个用于GUI界面）。
使用Cabal构建和管理多个相关Haskell软件包的最新实践是什么？
答案 0 :(得分：3)
我将这两个软件包放在不同的子目录中，并且Makefile有这样的内容：
.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
这假设您已经通过首先构建hoopl-core并注册它（--inplace）然后构建hoopl来引导该过程。您可以使用Makefile自动执行更多操作。
如您所知，当我们想要GHC的类似功能时，我们编写了自己的构建系统;-)我不建议这样做。从技术上讲，我认为可以从GHC构建系统中提取所需的部分并制作可重复使用的框架，但是...
答案 1 :(得分：2)
将两个包放入源代码管理存储库的单独子目录中，并使用两个单独的cabal文件。
确保在移动文件时使用源代码管理系统的移动操作，以便正确跟踪历史记录。