编译构建，从底层到高层

上古时期

最初的时候，我们手头上就只有一个gcc。不管干什么都一把梭，直接调用gcc来编译项目。项目文件不多的时候确实能够满足需求。但是多人协作，项目大了起来以后，这种方法及其容易造成混乱，并且工作量太大。

封建时期

后来我们就有了make和makefile。这是一套全自动化的解决方案，它能根据我们所定义的规则，自动化的去编译构建。一个工程会按照不同的功能，模块，类型等方式分门别类的放置各类源代码文件，资源文件，临时文件。而makefile所作的工作就是定义整个工程的编译规则。这些规则指示了哪些文件需要先编译，哪些可以后编译。此外，makefile能够有效地描述项目文件之间的依赖关系和处理命令，当只修改了个别文件后仅需要执行必要的处理，不必将整个项目全部重新编译一遍，极大的提高了开发效率。
但是make存在两个问题。其一是项目大了的时候，makefile会非常难写难理解，可维护性不强。其二是跨平台的问题，每次换平台，都需要重新修改一下makefile。

民国时期

接着就是CMake的时代了，虽然在本文中处于民国时期，但CMake应该是目前C/C++项目构建方式的事实标准。CMake是一个跨平台的编译工具，我的理解是它定义了一个编译抽象层，能够用自己内部定义的语句来生成各种各样的makefile/project给不同平台的make使用。我们所需要做的就是手动的编写CMakeLists.txt文件。

现代社会

对于Conan的认知，我觉得这是一个更为高层的，支持不同平台/编译器/构建工具/构建方式的解决方案。虽然是一个包管理器，但是我们可以利用它的脚本化操作来构建打包，下载上传包，解决依赖问题。
Conan需要搭配各类着构建工具来使用，但这些构建脚本在实现的时候不需要去考虑各类具体化的配置比如Debug还是Release，64位还是32位，静态库还是动态链接库，甚至于打包安装也都可以忽略掉，Conan都可以借助脚本完成，具体用法可以参考这篇博客。其次，Conan还解决了依赖的问题，构建的时候能够自动化的拉取对应的依赖库。