5

我正在研究用 Haskell 编写的基于数据流的优化库。现在看来，图书馆很可能不得不分成两部分：

  • 具有最小构建依赖关系的核心部分；叫它hoopl-core。

  • 一个完整的部分，称为它hoopl，它可能对诸如漂亮打印机、QuickCheck 等包有额外的依赖关系。

这个想法是 Glasgow Haskell 编译器将仅依赖于hoopl-core，因此引导编译器不会太困难。其他编译器将在hoopl. 包hoopl将取决于hoopl-core.

Debian 软件包工具可以从一个源代码树构建多个软件包。不幸的是，Cabal 还没有达到那种复杂程度。但是肯定有其他库或应用程序设计者有类似的问题（例如，一个包用于核心库，另一个用于命令行界面，另一个用于 GUI 界面）。

目前使用 Cabal 构建和管理多个相关 Haskell 包的最佳实践是什么？

4

2 回答 2

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 构建系统中提取所需的部分并制作一个可重用的框架，尽管......

于 2010-07-04T15:39:18.297 回答
2

将这两个包放入源代码控制存储库的单独子目录中，并使用两个单独的 cabal 文件。

确保在移动文件时使用源代码控制系统的移动操作，以便正确跟踪历史记录。

于 2010-04-13T07:44:47.423 回答