提升 C++ 开源项目的依赖性？答案

【问题标题】：Boost dependency for a C++ open source project?提升 C++ 开源项目的依赖性？
【发布时间】：2010-09-12 15:22:33
【问题描述】：

Boost 旨在成为每个 C++ 用户都可以使用的标准非标准 C++ 库。假设它可用于开源 C++ 项目是否合理，或者它是一个太大的依赖关系？

【问题讨论】：

标签： c++ boost standard-library

【解决方案1】：

基本上，您的问题归结为“将 [free library xyz] 作为 C++ 开源项目的依赖项是否合理。”

现在考虑一下 Stroustrup 的以下引用，答案真的很简单：

没有好的库，大部分有趣的任务都很难完成 C++；但是如果有一个好的库，几乎任何任务都可以轻松完成

假设这是正确的（根据我的经验，它是正确的）那么编写一个大小合理的 C++ 项目没有依赖是完全不合理的。

进一步发展这个论点，在（开发人员的）客户端系统上可以合理预期的一个 C++ 依赖项（除了系统库）是 Boost 库。我知道他们不是，但对于软件来说，这并不是一个不合理的假设。

如果一个软件甚至不能依赖 Boost，它就不能依赖任何库。

【讨论】：

查看 Anders 对 bcp 实用程序的回答。这将使我们能够在我们的项目中使用 boost，而我们过去由于大小而避免使用它。
@Mark 我不明白“由于大小”的答案。 Boost 是一个库集合。这些库中的大多数都很小。不需要单独的工具。
如果它们中的大多数尺寸都很小，我想我不想使用它们。我见过的那些是如此相互关联，以至于它们最终使我们的代码 tarball 膨胀了数十兆字节。我们向客户提供他们希望能够在多个 linux 发行版上编译的代码。版本之间有太多变化，无法简单地告诉我们的客户 boost 是一个先决条件。巨大的 boost 阻止我们将它与我们的代码捆绑在一起。 boost 库开发人员似乎从未考虑过限制代码大小。例如boost_1_49_0/boost/typeof/vector200.hpp 在一个源文件中超过 2MB
"如果一个软件甚至不能依赖 Boost，它就不能依赖任何库。"我刚刚检查了一下，标准的 boost 发行版包含大约 40,000 个源文件……这真是一个依赖！
我不会支持或反对使用 Boost！与大多数库相比，我只是说这是一个严重的依赖项。在我当前的项目中，我还有其他几个依赖项——它们的大小加起来只是 Boost 大小的一小部分。但是，如果您需要它来实现核心功能，那么您真的需要它！所以答案不是“如果一个软件甚至不能依赖 Boost，它就不能依赖任何库。”但“这取决于。”

【解决方案2】：

看看http://www.boost.org/doc/tools.html。具体来说，如果您想将 boost 依赖项嵌入到您的项目中，bcp 实用程序会派上用场。网站摘录：

“bcp 实用程序是一种用于提取 Boost 子集的工具，它对于希望将其库与 Boost 分开分发的 Boost 作者以及希望将 Boost 子集与他们的应用程序一起分发的 Boost 用户非常有用。

bcp 还可以报告您的代码依赖于 Boost 的哪些部分，以及这些依赖项使用了哪些许可证。”

当然，这可能有一些缺点 - 但至少您应该意识到这样做的可能性。

【讨论】：

【解决方案3】：

我以前对向系统引入依赖关系非常谨慎，但现在我发现依赖关系并不是什么大问题。现代操作系统带有包管理器，这些包管理器通常可以自动解决依赖关系，或者至少可以让管理员轻松安装所需的内容。例如，Boost 在 Gentoo-Postage 下作为 dev-libs/boost 可用，在 FreeBSD 端口下作为 devel/boost 可用。

现代开源软件在其他系统上构建了大量内容。在recent study 中，通过跟踪 FreeBSD 包的依赖关系，我们确定在我们的 FreeBSD 4.11 系统中的 12,357 个端口包，总共有 21,135 个库依赖项；即，除了作为基本系统一部分的 52 个库之外，它们需要一个库才能编译。库依赖包含 688 个不同的库，而单个项目使用的不同外部库的数量在 1 到 38 之间变化，众数值为 2。此外，5,117 个项目使用了至少一个外部库，405 个项目使用了 10 个或更多.

最终，您的问题的答案将来自成本与收益分析。重用成熟、广泛使用、经过审查和测试的库（如 Boost）的好处是否大于依赖项的低成本和不断下降的成本？对于 Boost 工具的任何重要用途，答案是您应该继续使用 Boost。

【讨论】：

【解决方案4】：

这取决于。如果您在 Boost 中使用仅定义类模板的头文件 - 那么可以继续使用它，因为它不会吸收任何 Boost 共享库，因为所有代码都是在编译时生成的，没有外部依赖项。版本控制问题对于任何共享的 c++ 库来说都是一个难题，而 Boost 也无法幸免，因此，如果您可以完全避免该问题，那将是一件好事。

【讨论】：

【解决方案5】：

在编写 C++ 代码时使用 boost 的好处远远超过了分发开源代码的额外复杂性。

我在 Programmer's Notepad 上工作，代码依赖于 boost 以进行测试、智能指针和 python 集成。由于要求，已经有一些投诉，但如果他们想处理代码，大多数人都会继续这样做。接受 boost 依赖是我从未后悔的决定。

为了稍微降低其他人的复杂性，我为 boost python 包含了版本化的预构建库，以便他们需要做的就是在其包含目录中提供 boost。

【讨论】：

【解决方案6】：

KDE 也依赖于 Boost。

但是，这主要取决于您的目标，甚至更多取决于您的目标受众，而不是您的项目范围。例如 TinyJSON（非常小的项目），几乎是 100% Boost，但这很好，因为它提供的 API 类似于 Boost，并且针对需要 JSON 绑定的 Boost 程序员。然而，许多其他 JSON 库不使用 Boost，因为它们针对的是其他受众。

另一方面，我不能在工作中使用 Boost，而且我知道许多其他开发人员（在他们的日常工作中）都在同一条船上。所以我想你可以说如果你的目标是开源的，并且一个使用 Boost 的组，请继续。如果您的目标是企业，您可能需要考虑一下，并从 Boost 中复制粘贴必要的部分（并承诺他们的支持），以使您的项目能够正常工作。

编辑：我们不能在工作中使用它的原因是因为我们的软件有可移植到大约 7 种不同的平台和跨 4 个编译器。所以我们不能使用 boost 因为它没有已证明兼容我们所有的目标，所以原因是技术一。（我们对开源和 Boost 许可部分，当我们将 Boost 用于其他事情时次）

【讨论】：

我很好奇你为什么不能在工作中使用它，害怕开源风险？还是更多技术原因？
我认为 boost 会定期在 12 个系统和 10212 个编译器上进行测试？（当然夸大了）。但我知道他们在很多系统上做了很多测试。
是的 Boost 在大多数平台上运行良好，但对于关键的嵌入式设备（如军事和医疗）和许多游戏机（我的情况），不能保证它会正常工作（并且有在某些平台上被破坏的情况）。

【解决方案7】：

我会说是的。 Mandriva（基于Red Hat）和Ubuntu（基于Debian）都有用于Boost 库的软件包。

【讨论】：

是的，我注意到它已打包（例如在 MacPorts 上），但它相当大。其他一些人回答说它有投诉

【解决方案8】：

我认为 Boost 提供的广泛功能，正如你所说，它是标准的非标准 C++ 库，证明它是一个依赖项。

【讨论】：

【解决方案9】：

不幸的是，对于 ubuntu，它们很容易获得，但对于 RHEL 4&5，我几乎总是最终使用 tarball 制作它们。它们是很棒的库，只是非常大......就像有时你真正需要的只是一个图钉时使用一个铁轨钉。

【讨论】：

【解决方案10】：

这完全取决于您使用 Boost 的方式。正如 Diomidis 所说，如果您要使用 Boost 的一些重要设施，那就继续吧。使用图书馆不是犯罪。

当然，有很多人不喜欢使用 Boost，因为引入新的依赖项总是有一些缺点和额外的担忧，但是在一个开源项目中......在我看来，如果你只是使用它们甚至可以想要学习它们或提高你的技能。

【讨论】：