使用 CMake 的 C++交叉编译项目管理第三方库依赖的最佳实践？

C++的依赖管理有几种。
vcpkg，conan。或者包进 nuget 里。我们自己用的一个魔改过的 Gradle。
其实改个 Gradle 插件是最简单的，或者 Conan 也可以。直接用 Artifactory 存编译好的二进制。你在编译的时候需要的依赖都会拉取对应版本到本地，解压链接进去。如果本地有的话那就直接用缓存。
自己控制好版本和 Arch 依赖关系就可以了，改个现有的系统的话，这些基本都有办法解决。
其他的不推荐，特别是你这种做法。到时候部署版本出了问题，你都没办法追踪依赖版本。而且根据环境不一样，有的时候你编译的二进制也不一定一样。这时候你再去追踪调试就更没谱了。
依赖最好是固定好的，对于 C++来说，不要去直接依赖代码。除非你是 boost 那样直接复制进去就能用的，不然全部都依赖二进制。然后这些二进制如果是开源的最好你要么直接依赖官方发布的二进制，要么全部自己编译。而且记录好编译环境参数等信息。有些项目在编译的时候会读入环境变量，这种你更没法控制发布版本了。
所有你依赖的库，全部都依赖其二进制。然后编译过程中通过依赖管理系统去下载这些二进制，让依赖管理系统去解决版本号，Arch，冲突等等问题。不要自己手动去解决。
你现在这种做法不出问题就罢了，真的你哪个依赖库有问题导致发布版本出错，查都没得查。

@secondwtq 感谢回复！你说的应该是目前的主流操作。没这么做的最大的原因我没写出来，这个是学校实验室的项目，其他成员基本上没有 linux 的使用经验，甚至 cmake 是什么都不知道，最好是源码一拉在 IDE 里面点个运行就能跑起来。。目前只能是写个脚本完成这些操作了。

@Mithril #3 感谢回复！ Conan 可能是我想要的东西，之前没有听过，明天好好学习一下！

所以说 c++更流行让二进制跟着源码走吗？之前有想过我自己提前编译好静态的.a 文件，每个 arch 分开放好，跟 source 一起版本控制，后来觉得应该尽量用源码而不是二进制，就没有尝试了。

@mrcn #5 补充，提前静态编译好第三方库的.a 文件，与项目的源码放在一起版本控制。

@mrcn 不是
因为 C++不像 Java 或者 Javascript 一类的直接使用源码（字节码也算直接使用源码了）它用的是针对平台特化的二进制。所以没办法像其它语言一样直接拉同样一份库就能用。你得针对不同平台甚至不同 STL 编译出一份来。也没有像 Maven 或者 NPM 一样的东西，不然同一份代码你得编译几十上百份二进制存进去。
我了解到的，主流的都是在你公司内部部署一个包管理系统，因为特定某个产品支持的平台一般都是有限的，所以你可以只放有限的几份上去。
你说的这个并不是主流做法，版本控制系统设计来是针对纯文本的，它的 diff 并没办法很好的处理二进制。你也不应该把二进制提交到代码库里。
正常做法是，你开发了一个版本的代码，CI 编译成针对某个或者某几个平台的二进制并生成版本号，然后 CI 把这些二进制传送到二进制管理系统里。
使用这些东西的项目，会在编译期由 Build Automation 系统去二进制管理系统里面查询对应版本号（你可以把架构直接写到版本号或者 product id 里）的二进制，并下载回来解决依赖。
至于你说的代码版本和二进制版本的对应关系，CI 系统会有记录。而且很多时候你也会把这个代码版本记录到二进制的包里，或者直接打到文件属性上。
不要把二进制放到代码库里还有个原因，就是你只放二进制的话没有编译环境记录的。CI 系统会记录每次编译使用的环境变量，编译参数，而且还有 log 可以查。而且你会把 pdb 一类的东西也放到二进制管理系统里。你在代码库里提交一个二进制，甚至都不一定能和代码对应的上。到时候出了问题查起来就是灾难了。

travis 拉 github 的依赖又不会很慢。。

如果你用本地的 CI，那建议 repo 也放本地，然后把所有依赖的库源码都在本地镜像一份

不要放预编译好的 binary，除非这个 binary 是 CI 的其它 pipeline 生成的，那可以通过 API 把其它 pipeline build 好的 artifacts 拉回来，否则 CI 还是尽量保证从头 full build

可以试试 xmake 原生支持各种 c++依赖包管理 https://xmake.io

推荐一个 cmake 的 module，叫 CPM： https://github.com/TheLartians/CPM.cmake，
自己改了改加了点小功能用起来很舒服，可以控制依赖项版本，CI 上只要有新版 cmake 和 git 就能用，如果依赖已经通过其他 package manager 安装会优先调用 system wide 的包。
我已经把这玩意作为写 cpp 新项目的标配了

@cuminflea 另外这玩意其实就是个 fetchContent 加个壳和一些自动化。。。

一般 CI 都是通过所谓的控制变量的方式来检查，也就是说，变量在一次运行中只会有一个。拿你的问题来说，依赖讲道理在代码有变化的情况下应该是不变的。那基于这样的假设的话，第一种方式实际上比较靠谱。然后每隔一段时间，手动或者自动的更新一下依赖，并且顺带测试一把这些依赖和你们项目的兼容性。至于你说最终部署的，CI 可以和最终的部署有两套环境，只需要在每次 release 的时候测一把就好了。

选项 1、3 都可以用 pkg-config 啊，1 的话直接安装到系统里，3 的话设置一个 prefix 安装到指定路径然后缓存就好，而且提前编译不是一定要编译成动态链接库，静态库 .a 文件了解一下。

我就是用的 3 这种。无非是加一个自定义 target 然后调用脚本。
https://github.com/atframework/prebuilt-build-tools
我还特意另写了个工程专门用来搞 prebuilt 的

看到楼主的 append，来联动一下隔壁 https://v2ex.com/t/643161

我小时候家里订了 2004 年到 07 年的电脑爱好者。当时这个杂志有个论坛，人还不算少，我没事就上去水水（跟 V 站似的），里面有个编程区，没事讨论些 Win32 编程之类的东西。现在看起来平均年龄和 V 站也差不多。
我当时只会 VB6，于是只能喊 666。有次问了个也不知道什么问题（好像是类似“怎么学编程”之类的），被人问了“你不是科班出身的？”，我当时还不知道“科班”是啥意思 ...

楼主链的这个博主 KingsamChen，当时好像是这个区的版主。
后来过了几年，论坛这个东西彻底过气了，再去看原来的站已经没了。没想到人还能找到。

@secondwtq 那你现在大可以去跟他交个朋友啦

@mrcn cmake 3.14 后有了 FetchContent_MakeAvailable 那才叫一个爽。

@wutiantong 现在用 @cuminflea 推荐的 CPM，也很爽，嘿嘿。只是 CMake 最低要求又从 3.11 刷到 3.14 了，都快顶到天花板了

@secondwtq 那个博主是个大牛，博客里有很多有价值的东西