问多第三方依赖的大型跨平台C++项目磁盘上的物理布局

EN

我正在重新组织具有许多第三方依赖项的大型跨平台C++项目的物理(磁盘上)布局，该布局使用CMake构建。

由于我们需要支持Windows，这是一个没有完善的包管理器的平台，我们很久以前就决定在源代码树中包含我们所依赖的第三方库。然而，在我们支持的其他平台上，例如Linux和Mac，许多第三方库都可以作为包使用，或者已经存在于系统中，并且很容易被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)是非常大的，因为包含了第三方库(它可能包含许多非源文件，如文档、测试数据等)，而且每次更新它们时，都会变得更大。不幸的是，这里没有办法，除非我们决定用一个新的存储库重新启动(不幸的是，丢失了整个提交历史)。
• 其中许多包括第三方库(例如zlib、libpng)对于在Linux或Mac上构建项目的用户根本不需要，尽管它们大大简化了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文件需要进行修改，以便为每个库在正确的位置查找第三方头文件和库。

在本地跨平台项目中处理第三方库的最佳实践是什么？哪种布局将为我们的开发人员在各自的平台上带来最不令人惊讶的构建体验？现有项目成功布局的具体例子也值得欢迎。