本文绝大部分理念学习并撰写（抄袭）自同僚大佬提供的知识概念
1.why we use conan
c++依赖管理的痛点是什么？是Dependency Hell
网状依赖、循环依赖、依赖渲染
当你拿到别人的代码时：
就算拿到也不一定能编的过，就算编的过也不一定能跑，就算能跑也不一定正常工作（即使代码本身没有问题）
一个应用级的项目可能会由许多团队共同开发，大家都以自己的方式纯手工维护依赖，版本号，编译属性，编译平台等，没有统一规则，没有自动化维护和重现，每个团队都更习惯自己造轮子或者代码级重用（如拷贝h和cpp到自己的工程项目里）
“为什么自己造轮子？你那玩意我编都编不过啊！”
所以由此引出了c++依赖管理的目标
2.what we want from conan
工程开发过程中引用别人的轮子，要尽可能方便
工程中的项目依赖可以被自动化维护，自动推导出正确的编译顺序
源代码和编译产物之间可以被正确管理，代码可追溯，可重现
依赖关系可视化
then we use conan！
3.conan基础用法
例子：我想写一个程序，需要依赖opencv但是版本必须大于3.2.0，小于4.0.0
CMakeLists.txt中添加
include(${CMAKE_BINARY_DIR}/conanbuildinfo.make)
conan_basic_setup()
target_link_libraries(test ${CONAN_LIBS})
conanfile.txt中
[requires]
opencv/[^3.2.0]@navi/thirdparty
[generators]
cmake
然后去执行conan install去生成conanbuildinfo.cmake
mkdir build cd build conan install ..
REFERENCE： {repo_name}/{version}@{user}/{channel}(例：opencv/3.4.0@navi/thirdparty)
执行完conan install，远端服务器会根据你的conanfile.txt找到符合你依赖要求的版本，自动执行conan download获取到本地路径（默认在~/.conan/data路径下，下面称为local cache）
此时你的local cache里会有conan的recipe描述文件（名字和版本号，源码仓库位置，支持的编译平台等），source包（里面有该库的源码），package（编译好的包，通常为头文件和lib）
在你的~/.conan/profiles目录下，可以按照编译环境的编译要求自行修改(如修改编译器版本要求、编译平台、docker镜像等待)
conan install .. #是按照~/.conan/profiles/default的配置去执行install
conan install .. -pr=armv8-dr #是按照~/.conan/profiles/armv8-dr的配置去执行install
install会直接从你的conan云端拉取到符合你的环境的编译好的依赖，如果你的云端没有相对应环境编译好了的依赖包怎么办？
别慌，只要你上传过该依赖并且没有删掉，conan会去直接找你代码的git远程仓库，从远程仓库把代码拉下来并当场按照你的环境编译。
是不是贼爽，贼酷炫？这不赶紧上手学习？
再去根据conan去编译的时候，就会去local cache里面去找已经编译好了的依赖包
conan build .. -sf .. -bf .
学习和理解的过程是痛苦的，熟练运用后会体味到统一依赖管理的香甜
此随笔只是简要介绍conan所解决的问题以及优点和浅要概念，所以想靠这篇文章搞一个基本的conan项目是不现实的（大牛除外）
后续会在“从零开始的conan”分类下更新一些更全面的命令用法，以及实战！
