人们喜欢讨厌构建系统。 仅仅观看 CppCon17 上的演讲,就能够看到开发人员由于构建系统而闹笑话的例子。 这让咱们思考一个问题:为何会这样? 构建系统时固然不可能天衣无缝。 但我认为,在 2018 年,咱们能够很好地解决其中的一些问题。 这就是 CMake。不过 CMake 2.8 可能不行; 它在 C++11 发布以前就 release 了! 对于 CMake 来讲也没有可怕的例子(甚至那些发布在 KitWare 本身的教程列表中的例子)。 咱们来谈论现代 CMake。CMake 3.1+,甚至多是 CMake 3.15+! 它整洁,强大,优雅,所以你能够将大部分时间花在编码上,而不是编写不可读,不可维护的 Make(或CMake 2)文件。 固然,CMake 3.11+ 运行起来也应该明显更快!git
简而言之,若是你在考虑使用现代 CMake,这些多是你最关心的问题:安全
下面哪几点适合你?网络
若是是这样,你将受益于相似 CMake 的构建系统。ide
构建系统是一个热门话题。 固然你们有不少选择。但即便是很是好的,或者重用一个熟悉的语法,也没法和 CMake 相提并论。 为何?生态支持。 每一个 IDE 都支持 CMake(或 CMake 支持这些 IDE)。 有更多的软件包在使用 CMake 而不是其余构建系统。 所以,若是你在使用一个软件包,它被设计为包含在你的代码中,你能够选择:建立本身的构建系统,或使用一个它支持的构建系统:这些软件包几乎老是支持 CMake。 若是你要使用多个软件包,CMake 将很快成为共同点。 并且,若是你须要一个预安装软件包,那么它有 CMake 查找或配置脚本的可能性很是高。wordpress
大约 CMake 2.6-2.8 的时候,CMake 开始流行起来。出如今了大多数 Linux 操做系统的软件包管理器列表中,而且被用于许多软件包使用。 而后 Python 3 问世了。 我知道,这与 CMake 没有任何关系。 但它是第三版。 它前面有一个第二版: 这是一个艰难,丑陋的过渡,即便在今天,一些软件仍然还在使用第二版。工具
我相信 CMake 3 运气不会比 Python 3 好到哪儿去。1 尽管每一个版本的 CMake 都是努力向后兼容,但 CMake 3 系列任然被视为新东西。 所以,你会发现操做系统,像 CentOS 7,已经拥有 GCC 4.8,几乎彻底支持 C++ 14,还在使用在 C++ 11 以前就推出的 CMake 2.8。gitlab
你真的至少应该使用编译器发布以后出现的 CMake 版本,由于构建系统须要知道新版本编译器的编译标志等信息。 并且,因为 CMake 会将本身退化为 CMake 文件中指示的所需的最低版本,所以,即便你在系统范围内安装一个新的 CMake,也是很是安全的。 或者你至少应该在本地安装它。 这很容易 (大多数状况下也就一两行代码的事儿), 你会发现 5 分钟的工做将为你节省数百行和几小时的 CMakeLists.txt
编写时间,而且从长远来看将更容易维护。 本书试图解决那些网络上随处可见的糟糕问题和例子,以及提出最佳实践的方法。ui
在网上还有一些其余地方能够找到有用的信息。下面是其中的一些:编码
现代 CMake 最初由 Henry Schreiner 编写。其余贡献者信息能够 GitLab 项目贡献者列表 中找到。
1. CMake 3.0 还从很是旧版本的 CMake 中删除了几个长期弃用的功能,并对与方括号相关的语法作了一个很是微小的向后不兼容的更改,因此这不彻底公平; 可能会有一些很是很是古老的 CMake 文件在 CMake 3+ 中不能运行;虽然我历来没有见过。 ↩