刚看了一点,大意就是:开发过程中,会用到一些外部包,要各种配置开发环境,包的版本发布管理等等问题,现在要解决它。
当前基于源码依赖的 开发模式 弊端:
- 对于外部库的依赖, 通常各个工程师在自己电脑安装, 坏处是 安装繁琐(有的要源码编译,有点命令安装, 不同人装的可能是不同版本号)
- 对于内部依赖, 当前都是通过git源码依赖, git submodule管理. 带来两个问题: 源码编译时间太长, 对submodule没办法 分版本管理, 不好做分支管理; 而没有版本发布管理, 会带来协同开发/项目管理问题
- 源码权限管理 问题: 因为是源码依赖, 导致 使用方 需要申请所有依赖仓库的权限
- 源码仓库直接依赖, 一个git仓拉下来不能编译,必须在同级目录拉个其它依赖, cmake文件到处是 基于目录结构的依赖
一个好的解决方案就是使用conan.
它不生产你需要的外部包,而是提供一个工具,帮你获得它。具体就是,你现在需要一些包,通过conan去搜索你需要的包并且下载下来(Conan能帮你从外部资源比如github中帮你去找,一般是ConanCenter)。
这个时候我们写一个文件:conanfile.txt 。给自己的程序指定相关的依赖,然后Conan根据这个文件,在本地,将刚才下载的包 打包为二进制文件。举例:Conan除了安装了直接依赖的Poco,还安装了间接依赖的OpenSSL和zlib库。
同时它为我们的构建系统产生了conanbuildinfo.cmake文件。
现在我们使用cmake对自己的程序编写CmakeLists.txt文件,这个文件要包含刚刚conan自动生成的conanbuildinfo.cmake文件。
最后正常使用cmake对自己的程序进行编译等工作就行了。
conan使用package_id()函数能保证兼容?
其实是不能的。因为它本质上是不提供不同编译设置的包。
举例,你用gcc 4.9做的conan包用在自己工程上,你同事gcc 4.8做的包也能正常使用。那么别人从外部下载你的gcc 4.9的包,但是他的编译器是gcc 4.8的,这个时候,你可以在package_id()函数里面告诉他,gcc4.8版本的包找不到的话,可以用我的gcc4.9的包,我作为开发人员,我验证过了。而不是我给你生成一个gcc4.8的包。