相关疑难解决方法(0)

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

由于我们需要支持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 …