我想开发一个可以在许多不同平台上构建的项目。 项目代码将使用 C++，管理库的最佳方式是什么？
我计划使用 bjam 作为构建系统，因为我也将依赖于 Boost 及其单元测试框架。
两个依赖是Boost本身和FLTK。
图书馆管理的可能性是:
- 在树中包含所有受支持平台的构建工件(二进制文件)和 header
- 在树中包含所有库依赖项的完整源代码，并以某种方式将它们编写为依赖项
- 1 和 2 的组合，就像 node.js 对 v8 所做的那样
- 通知用户他们需要自己构建库，然后将它们放在 PATH 或某个特殊目录中，就像 libcurl 对其依赖项所做的那样
- 依赖 *nix 构建工具(即 libtool)mozilla 风格，然后告诉用户他们必须使用 MSYS 在 windows 上构建
这里最好的方法是什么？ 在接下来的六个月里，该项目可能不会超过几千行，但我想在这里做出正确的选择，这样我以后就不必再回来更改所有内容了。
最佳答案
这是一个主观的答案。
首先，关于 Boost:一旦构建了 Boost，无论以何种方式，您都不需要使用 bjam。因此，您可以使用任何适合您的构建系统，同时要求某些库位于系统上或特定路径中，无论它们是如何构建的。作为旁注，大部分 boost 都是仅 header (即使是单元测试框架也可以使用仅带 header 的 IIRC，但建议使用库版本)。假设您需要 boost 二进制文件。
处理项目 IMO 的最佳方法是使用您自己选择的最适合您自己的项目的构建系统，并需要“预构建”的依赖项( boost )。它们的预构建方式取决于每个依赖项；有些可能会使用您选择的相同构建系统，其他人会使用他们自己的构建系统。有些将适用于所有平台，例如，有些将在 Windows 上编译但没有适合 Windows 的最佳构建系统。如果它们是小型库，您可以将它们集成到您的构建系统中，否则只需将它们视为开发人员在构建您的项目之前“以某种方式”必须拥有的“依赖项”。这里的“不知何故”将在 README 中进行解释。
例如，我在我的项目中使用 cmake，但在我的项目中使用 boost 和其他一些库。 cmake 允许我为 MSVC、C::B、GNUMake 等生成项目文件，但是我不希望我的所有依赖项也使用 cmake。对于非常小的、稳定的库，我可以为它们做一个 cmake 项目，然后事情就真的很简单了。对于更大或更易变的库，最好将每个库留给自己的构建系统。 volatile 库经常变化，所以如果你为它们构建任何“定制”的东西，你将不得不不断地调整你的“定制”以适应库中的变化。对于我使用的每个库，我都有一些 cmake 变量，例如 BOOST_LIB_INCLUDE_PATHS 和 BOOST_LIB_LIBRARY_PATHS 以及 BOOST_LIB_LIBRARIES，开发人员编译我的项目时可以将它们定义为它们的值。 cmake 确实提供了一些神奇的库搜索功能，但我发现这种魔法很丑陋，所以我明确要求将路径设置为变量。
您可以自行决定是否向这些库提供源代码；这没什么不对，尤其是在你想依赖库的特定版本的地方。但是将它们编写为依赖项的脚本可能会变得一团糟，除了维护易变库之外。
但是，我知道当构建 Google Chromium 项目时，会下载、检查、构建和链接大约一百个库。 Chromium 使用 GYP 作为构建系统 IIRC。
关于c++ - 使用 Boost.Build 和 C++ 管理库依赖关系，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12485441/