我正在重新组织一个大型跨平台 C++ 项目的物理(磁盘上)布局,该项目具有许多第三方依赖项,使用 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 文件需要修改以在每个库的正确位置查找第三方头文件和库。
在原生跨平台项目中处理第三方库的最佳实践是什么?哪种布局会为我们的开发人员在各自的平台上带来最出人意料的构建体验?也欢迎现有项目中成功布局的具体示例。