江湖人称菠萝包

读者已经跟着本书实践了很多零零散散的实例，应该能够熟练使用CMake来构建C和C++程序了吧！不过，前面的实例往往都是针对某个特定功能编写的，我们可能很难将它们综合起来实现一个完成度较高的项目。不必担心，本章就带领大家使用C++语言实现一个完整的动态库，以及调用该库的可执行文件——手写数字识别库和手写数字识别命令行工具。相信经过本章的实践，读者一定可以将前面所学的知识融会贯通，应用于中大型项目中了！

CMake相当重视向后兼容性，并且受益于此，能够持续不断地改进和增加新特性，而几乎不会破坏古老的代码仓库。这一点在第2章介绍CMake的特点时已经提到过。CMake的策略机制就是为解决向后兼容问题而生的。有了策略机制，CMake可以基本确保基于旧版本CMake编写的目录程序可以被新版本的CMake配置生成，同时，如果程序中使用了已经弃用的特性，它也能针对性地给出警告信息，鼓励或要求用户重构CMake程序。

尽管CMake内置了相当多软件包的查找模块，但难免还会有特殊的需求。本节将介绍如何自己编写一个查找模块。在查找模块的实现中，往往需要查找软件包所需的可执行文件、库文件、头文件目录等路径。CMake提供了一系列命令用以辅助完成这些工作。下面先介绍这些命令。

关于这两个命令中的哪些参数支持生成器表达式，第7章中均已介绍，这里不再赘述。

属性用于定义编译（预处理）C和C++程序时所用到的宏。该属性值为列表字符串，每一个元素都代表一个宏定义。其元素格式为<宏名称>或<宏名称>=<值>。属性用于定义库目标对使用者的宏定义要求。任何构建目标，若链接到具有该属性的库目标，都会定义该属性所要求的宏。换句话说，该属性作为使用要求，会被自动传递给依赖者的构建要求。该传递过程由CMake在配置生成阶段隐式地完成，并不会改变依赖者的属性。属性仅包含为目标自身定义的构建要求，不包含传递过来的构建要求。

从本章开始，我们不再仅仅停留在CMake脚本程序中，而是开始将CMake看作一个用于构建项目的利器了。在了解CMake的具体用法之前，先要清楚地掌握CMake项目的构建流程。换句话说，就是要清楚地掌握CMake项目的生命周期——从源程序和CMake目录程序，到构建好的二进制文件，再到这些二进制文件的安装和打包分发，最终到其他项目的源程序借助CMake使用这些二进制文件提供的功能。本章会说明CMake是怎样实现这样一个生命周期的，重点介绍其构建项目过程中的6个阶段，尤其是与构建紧密相关的阶段。

到这里，终于将CMake中比较常用的命令都讲解完了。本章是本书中第一个实践章节。实践章节不会介绍任何的新内容，而是通过一个具体的项目来实战演练前面学习到的知识。鉴于之前我们一直把CMake当作通用脚本语言来学习，本章也不会含糊，直接实现一个经典算法：快速排序！快速排序的基本原理很简单：找到数列的一个基准值，将数列分成比该值小和比该值大的两部分子数列；变量，分别代表CMake脚本模式下命令行参数的个数及第N个参数的值（包括cmake命令行名称本身）。如果希望传递自定义参数到CMake脚本程序中，可以在调用。

CMake主要为构建服务，因此提供了专门生成宏定义的模板，可以非常方便地用于代码生成。例如，可以将定义在CMake程序中的版本号等信息以宏定义的形式生成到头文件中，并最终构建到可执行文件中。宏定义模板主要分为两种形式：一种是值为0或1的宏定义，另一种是自定义值的宏定义。后一种形式的自定义值可为空值，用于表示存在性。#cmakedefine01 <变量>#cmakedefine <变量> [<值>]#define <变量> 0/* #undef <变量> */如下所示中是一个实例。

CMake中有很多预定义的普通变量和环境变量，它们一般以“CMAKE_”开头，即属于保留标识符。预定义变量往往与系统配置、运行环境、构建行为、编译工具链、编程语言等信息相关。CMake中的预定义变量全部可以在其官方文档中找到，本书也会陆续涉及很多常用的预定义变量。在此先简单看一些预定义变量的例子。CMAKE_ARGC表示CMake脚本程序在被cmake -P命令行调用执行时，命令行传递的参数个数。表示CMake脚本程序在被命令行调用执行时，命令行传递的第一个、第二个参数。

CMake官网给出了如下的定义：CMake是一个跨平台开源工具家族，用于构建、测试和打包软件。CMake通过简单的平台无关且编译器无关的配置文件来控制软件的编译流程，并能够生成原生的Makefile和工作空间，以便用于用户所选择的编译环境。为了满足开源项目对强大的跨平台构建工具的需求，Kitware公司创建了CMake工具套装。定义中，“跨平台”和“开源”这两个特性不必多说，要注意的是“工具家族”这个说法。

结合前两个例程能够发现，使用要求在被传递时存在多种可能性：1．传递到使用者的构建要求；2．传递到使用者的使用要求；3．同时传递到使用者的构建要求和使用要求。前面两个例程分别对应第一种情况和第三种情况。第二种情况一般在当头文件（接口）使用了某个库，而源程序（实现）中并没有使用这个库时才会用到，多见于伪构建目标。举个另类但还算实用的例子：当希望引用一个接口库就可以自动链接多个库时，实际上就是要将多个链接库的使用要求传递给这个接口库的使用要求。接口库是伪构建目标，不需要编译，也就不存在构建要求。