管理相关Cabal包的最佳做法是什么?

Nor*_*sey 5 haskell packaging cabal

我正在研究用Haskell编写的基于数据流的优化库.现在看来,图书馆可能需要分成两部分:

  • 片具有最小构建依赖关系; 叫它hoopl-core.

  • 一个完整的部分,调用它hoopl,它可能对包,如prettyprinter,QuickCheck等具有额外的依赖性.

我们的想法是格拉斯哥Haskell编译器只依赖于hoopl-core它,因此引导编译器不会太困难.其他编译器将获得额外的好处hoopl.套餐hoopl将取决于hoopl-core.

Debian包工具可以从单个源树构建多个包.不幸的是,Cabal还没有达到那种复杂程度.但是必须有其他具有类似问题的库或应用程序设计者(例如,一个包用于核心库,另一个用于命令行界面,另一个用于GUI界面).

使用Cabal构建和管理多个相关Haskell软件包的当前最佳实践是什么?

Sim*_*low 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
Run Code Online (Sandbox Code Playgroud)

--inplace这假设您已经通过首先构建 hoopl-core 并注册它 ( ) 然后构建 来引导该过程hoopl。您可以使用 Makefile 自动执行更多操作。

如您所知,当我们想要 GHC 的类似功能时,我们编写了自己的构建系统;-) 我不建议这样做。从技术上讲,我认为可以从 GHC 构建系统中提取所需的部分并制作一个可重用的框架,不过......