管理相关 Cabal 包的最佳实践是什么？
我正在开发一个用 Haskell 编写的基于数据流的优化库。现在看来，该库可能必须分为两部分：
具有最小构建依赖性的核心部分；称之为
hoopl-core。一个完整的部分，称之为
hoopl，它可能对 PrettyPrinter、QuickCheck 等包有额外的依赖。
这个想法是 Glasgow Haskell 编译器将仅依赖于 hoopl-core ，因此引导编译器不会太困难。其他编译器将在 hoopl 中获得额外的好处。包 hoopl 将依赖于 hoopl-core。
Debian 软件包工具可以从单个源代码树构建多个软件包。不幸的是Cabal 还没有达到那种复杂程度。但肯定还有其他库或应用程序设计者也有类似的问题（例如，一个包用于核心库，另一个包用于命令行界面，另一个包用于 GUI 界面）。
使用 Cabal 构建和管理多个相关 Haskell 包的当前最佳实践是什么？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我将这两个包放在单独的子目录中，并有一个
Makefile，其内容如下：这假设您已经通过首先构建 hoopl-core 并注册它来引导该过程（
-- inplace），然后构建hoopl。您可以使用 Makefile 自动执行更多操作。如您所知，当我们想要 GHC 的类似功能时，我们编写了自己的构建系统；-) 我不建议这样做。从技术上讲，我认为可以从 GHC 构建系统中提取所需的部分并制作一个可重用的框架，不过......
I'd put the two packages in separate subdirectories, and have a
Makefilewith something like this:this assumes you've bootstrapped the process by first building hoopl-core and registering it (
--inplace) and then buildinghoopl. You could automate more of this using the Makefile.As you know, when we wanted similar functionality for GHC, we wrote our own build system instead ;-) I don't recommend that. Technically I suppose it would be possible to extract from the GHC build system the required pieces and make a re-usable framework, though...
将这两个包放入源代码控制存储库的单独子目录中，并使用两个单独的 cabal 文件。
确保在移动文件时使用源代码管理系统的移动操作，以便它正确跟踪历史记录。
Put the two packages into separate subdirectories of your source control repo, and use two separate cabal files.
Make sure you use the move operation of your source control system when moving files, so that it tracks the history properly.