c++ - 具有许多第三方依赖项的大型跨平台 C++ 项目在磁盘上的物理布局

Question

我正在重组 large cross-platform C++ project 的物理(磁盘上)布局具有许多第三方依赖项，使用 CMake 构建。

由于我们需要支持 Windows，一个没有完善的包管理器的平台，我们很久以前就决定将我们依赖的第三方库包含在源代码树中。但是，在我们支持的其他平台(例如 Linux 和 Mac OS X)上，这些第三方库中的许多都以软件包的形式提供或已经存在于系统中，并且很容易被 CMake 找到。

目前项目布局如下:

root/
    src/
        3rd-party-lib1/       (build system modified to output to build/)
        3rd-party-lib2/       (build system modified to output to build/)
        project-module1/      (our own code)
        project-module2/      (our own code)
    build/                    (CMake is invoked from here)
        3rd-party-lib1-bin/
        3rd-party-lib2-bin/

第三方库已经过调整，因此在构建时，它们将二进制文件输出到 root/build/<lib>/ .

这种布局的问题是多方面的:

• 第三方库不再是 100% 原创。这使得更新它们比所需的稍微困难一些。
• src/目录包含我们自己的代码和第三方代码的混合，这令人困惑。
• src/目录非常大。因为src/包含第三方库，与原始源代码的实际数量相比非常大，使得备份我们自己的代码比所需的稍微复杂一些(我们不能再只归档整个 src/ 目录)。
• 项目存储库 (Git) 非常大，因为包含第三方库(其中可能包含大量非源文件，例如文档、测试数据等)，并且每次我们更新它们时它都会变大。不幸的是，没有办法回到这里，除非我们决定用一个新的存储库重新启动(不幸的是丢失了整个提交历史)。
• 在 Linux 或 Mac OS X 上构建项目的用户根本不需要其中包含的许多第三方库(例如 zlib、libpng)，尽管它们大大简化了 Windows 用户的操作。

另一种布局如下:

root/
    3rdparty/
        3rd-party-lib1/       (100% original, contains built artifacts)
        3rd-party-lib2/       (100% original, contains built artifacts)
    src/
        project-module1/      (our own code)
        project-module2/      (our own code)
    build/                    (CMake is invoked from here)

我们的 CMake 文件需要修改以在每个库的正确位置查找第三方头文件和库。

在原生跨平台项目中处理第三方库的最佳实践是什么？哪种布局会为我们的开发人员在各自平台上带来最意想不到的构建体验？也欢迎现有项目成功布局的具体示例。

Answer 1

我的经验表明以下是最佳实践:

• 当完全按原样使用第三方开源库时，在主 git 存储库中提交下载的压缩 tarball 的本地拷贝，以避免网络连接问题阻止软件构建。

• 当第三方开源库几乎按原样使用，但需要进行调整时(这在交叉编译时很常见:许多包需要对其配置步骤进行轻微调整)，将压缩的 tarball 和“统一差异”补丁文件存储在主 git repo 中，并在 ExternalProject_Add 的 PATCH_COMMAND 步骤中应用补丁。

• 当您的组织(将)对第三方开源库进行大量修改或扩展时，使用单独的 git 存储库来保存指向上游存储库的指针(当它也使用 git 时最简单，但上游svn 也可以管理)。将您组织的更改提交到与用于镜像上游的分支不同的分支。如果您愿意，您可以在主 git 存储库和这个 git 存储库之间引入子模块关系，不过因为 DOWNLOAD_COMMAND 可以直接从任意 git 存储库获取，所以从技术上讲没有必要这样做。

• 通过将它们也存档在主 git 存储库中来处理针对单个目标平台的小型、不太常见的第三方专有二进制文件是合理的。但是，适用于各种平台、较大或经常演变的第三方二进制文件应存储在它们自己的 git 存储库中，并通过 DOWNLOAD_COMMAND 获取，如上所述。