一个多模式 Haskell 可执行文件与共享库的单独可执行文件

Question

我现在正在处理一个项目，在该项目中我配置 cabal 文件以构建多个可执行文件，这些可执行文件共享由同一个 cabal 文件构建的库。 cabal 项目的结构很像 this one，有一个 library 部分，然后是几个 executable 部分，这些部分在其 build-depends 部分中包含此库。

我正在使用这种方法，因此我可以为任意数量的可执行文件提供常用功能，并根据需要轻松创建更多可执行文件。

然而，在他的Monad Reader article on Hoogle p.33 中，Neil Mitchell 主张将 Haskell 项目捆绑到具有多种模式的单个可执行文件中（例如，通过使用 Neil Mitchell 的 CmdArgs 库。）因此可能有一种模式来启动 Web 服务器，另一种模式从命令行等方式查询数据库引用：

提供一个可执行文件

版本 3 有四个可执行程序 - 一个用于生成排名 信息，一个做命令行搜索，一个做网页 搜索，一个做回归测试。版本 4 有一个 可执行文件，它执行以上所有操作，由标志控制。 只提供一个终端程序有很多好处——它 减少了代码破坏而不注意它的机会，它使 通过不复制 Haskell 运行时系统，总文件大小更小， 它减少了用户需要学习的命令数量。移动到 一个多用途的可执行文件似乎是一个共同的主题，哪些工具 例如 darcs 和 hpc 都基于一个具有多个的命令 模式。

单个多模式可执行文件真的是更好的方法吗？是否有相反的理由坚持使用共享同一库的单独可执行文件？

Answer 1

就我个人而言，我更喜欢 Unix 哲学“编写只做一件事并把它做好的程序”。然而，这两种方式都有原因，所以这里唯一合理的答案是：视情况而定。

将所有内容捆绑到同一个可执行文件中的一个示例是，当您针对资源非常有限的平台（例如嵌入式系统）时。这是BusyBox采取的方法。

另一方面，如果您划分为多个可执行文件，您可以让您的客户选择只使用对他们重要的那些。使用单个可执行文件，即使您的客户真的只想要一个功能，他也无法摆脱额外的包袱。

我确信选择任何一种方式都有很多理由，但这只是表明没有明确的答案。这取决于用例。