C++ 编译依赖管理系统分析以及 srcdep 介绍

如果用 C++ 写一个中小型软件，有要用到很多第三方库的话，相信不少人会觉得比较麻烦。很多新兴的语言都有了统一的依赖管理系统和构建系统，但是 C/C++ 界一直没有比较正统的。（也不奇怪，连统一的 string 都没有，怎么可能有统一的依赖、构建体系？）

在上一篇，我们尝试选择一个构建体系的时候，一开始觉得 CMake 比较接近事实标准了。同样，CMake 也正在尝试把手伸到依赖管理上面。CMake 的理念一开始起源于 makefile，其实是比较简单、干净的，一个包有 include_dir、lib_dir 等，然后就可以构建了。但我的观点还是，Moedern CMake 把这一切都搞复杂了，它尝试面向对象地解决依赖问题+构建问题。但是它在 include_dir、lib_dir 之上发明了很多新的概念，增加了学习成本，掩盖了底层细节——C++er 一般不喜欢被隐藏细节，你好及解决问题也让我知道是怎么解决的。再加上 CMake 相对另类的语法以及看不懂的文档这两个 debuff，导致学习成本比起一般新事物高得多。所以，尽管它在市占率上可能ou 接近事实标准，我们还是把它当成一个普通的系统来看待，不给特殊待遇。何况，大家用 CMake 来构建的比例有多少、用来管理依赖的又有多少呢，说不清楚，我也没调查过。

C++ 领域，市面上是有一些的依赖管理系统的，但可能都没有形成大一统。我觉得可以按这几个角度去做分类：

• 源代码依赖还是二进制依赖
• 是否需要包仓库服务器
• 是否与构建系统绑定
• 依赖包跟系统还是跟项目