CMake最好的学习资料

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

CMake是一个开源的可扩展工具，用于独立于编译器的管理构建过程。CMake必须和本地构建系统联合使用，在每个源码目录中，需要编写CMakeLists.txt文件，以声明如何生成标准的构建文件（例如GNU Make的Makefiles，或者MSVS的解决方案）。

CMake支持所有平台的内部构建（in-source build）和外部构建（out-of-source build）。内部构建的源码目录和二进制目录为同一目录，即CMake会改变源码目录的内容。通过外部构建，可以针对单个源码树进行多重构建（Multiple builds ）。

CMake会生成一个方便用户编辑的缓存文件，当其运行时，会定位头文件、库、可执行文件，这些信息被收集到缓存文件中。用户可以在生成本地构建文件之前编辑它。

CMake命令行支持自动或者交互式的运行。CMake还提供了一个基于QT的GUI，其名称为cmake-gui。注意此GUI同样依赖于环境变量的正确设置。

CMakeLists.txt包含一系列的命令，每个命令都是COMMAND(args…) 的形式，多个参数使用空白符分隔。CMake提供了很多预定义命令，你可以方便的扩展自己的命令。CMake支持简单的变量，它们或者是字符串，或者是字符串的列表。引用一个变量的语法是${VAR_NAME} 。

如果向一个命令传递列表变量，效果等同于向它逐个传递列表成员：

要把一个列表变量作为整体传递，只需要加上双引号即可：

CMake可以直接访问环境变量和Windows注册表，前者使用语法$ENV(VAR) ，后者使用语法[HKEY_CURRENT_USER\\SOFTWARE\\path;key]

1. 支持多个底层构建工具，例如GNU Make、MSVC、XCode等等，可以生成这些构建工具需要的配置文件
2. 通过分析环境变量、Windows注册表等，自动搜索构建所需的程序、库、头文件
3. 支持创建复杂的命令
4. 很方便的在共享库、静态库两种构建方式之间切换
5. 自动生成、维护C/C++文件依赖关系，并且在大部分平台上支持并行构建

在开发跨平台软件时，CMake具有以下额外优势：

1. 可以测试机器字节序和其它硬件特性
2. 统一的构建配置文件
3. 支持依赖于机器特定信息的配置，例如文件的位置

C++源码：

要通过CMake编译上述文件，需要在同一目录下放置CMakeLists.txt文件：

在上述目录中执行下面两条命令，即可执行构建：

CMake包含一系列重要的概念抽象，包括目标（Targets）、生成器（Generators）、命令（Commands）等，这些命令均被实现为C++类。理解这些概念后才能编写高效的CMakeLists文件。

下面列出这些概念之间的基本关系：

1. 源文件：对应了典型的C/C++源代码
2. 目标：多个源文件联合成为目标，目标通常是可执行文件或者库
3. 目录：表示源码树中的一个目录，常常包含一个CMakeLists.txt文件，一或多个目标与之关联
4. 本地生成器（Local generator）：每个目录有一个本地生成器，负责为此目录生成Makefiles，或者工程文件
5. 全局生成器（Global generator）：所有本地生成器共享一个全局生成器，后者负责监管构建过程，全局生成器由CMake本身创建并驱动

CMake的执行开始时，会创建一个cmake对象并把命令行参数传递给它。cmake对象管理整体的配置过程，持有构建过程的全局信息（例如缓存值）。cmake会依据用户的选择来创建合适的全局生成器（VS、Makefiles等等），并把控制器转交给全局生成器（调用configure和generate方法）。

全局生成器负责管理配置信息，并生成所有Makefiles/工程文件。一般情况下全局生成器把具体工作委托给本地生成器执行，全局生成器为每个目录创建一个本地生成器。全局/本地生成器的分工取决于实现，例如：

1. 对于VS，全局生成器负责生成解决方案文件，本地生成器负责每个目标的工程文件
2. 对于Makefiles，全局生成器生成总体的Makefile，本地生成器则负责生成大部分Makefile

每个本地生成器包含一个cmMakefile对象，其中存放CMakeList.txt的解析结果。

CMake的每一个命令也被实现为C++类，该类主要包括两个成员：

下图显示cmake、生成器、cmMakefile、命令等类型的关系：

cmMakefile对象中存放的最重要的对象是目标（Targets），目标代表可执行文件、库、实用工具等。每个add_library 、add_executable 、add_custom_target 命令都会创建一个目标。

下面的语句创建一个库目标：

上述命令声明的foo可以作为库名称在工程的任何地方使用。CMake知道如何将此名称转换为库文件。命令的（可选的）第二个参数声明库的类型，有效值包括：

如果不声明库类型，则CMake依据变量BUILD_SHARED_LIBS 判断应该构建为共享库还是静态库，如果此变量不设置，构建为静态库。

与库目标类似，可执行目标也可以指定特定的选项，例如WIN32会导致操作系统调用WinMain而不是main函数。

使用set_target_properties 或者get_target_properties 命令，或者更通用的set_property 、get_property 命令，可以读写目标的属性。一个最常用的属性是LINK_FLAGS ，可以指定链接标记。使用target_link_libraries 命令，可以指定目标需要链接的库的列表。列表的元素可以是库、库的全路径、通过add_library命令添加的库名称。

对于声明的每个库，CMake会跟踪其依赖的所有其它库，这种依赖关系需要用上述命令来设置：

和Target类似，源文件也被建模为C++类，也支持读写属性（通过set_source_files_properties、get_source_files_properties或更加一般的命令）。最常用属性包括：

其它偶尔可能用到的CMake类型包括Directory、Generator、Test、Property等。Directory、Generator、Test的实例同样（与目录、源文件类似）关联属性。

属性是一种键值存储，它关联到一个对象。读写属性最一般的方法是上面提到的get/set_property命令。所有可用的属性可以通过cmake
-help-property-list 得到。

目录的属性包括：

目录和生成器对象会在CMake处理你的源码树时自动创建。

CMakeLists中的变量和普通编程语言中的变量很类似，变量的值要么是单个值，要么是列表。CMake自动定义一系列重要的变量。

要引用变量，必须使用${VARNAME} 语法，要设置变量的值，需要使用set命令。CMake中变量的作用域和普通编程语言略有不同，当你设置一个变量后，变量对当前CMakeLists文件、当前函数、以及子目录的CMakeLists、任何通过INCLUDE 包含进来的文件、任何调用的宏或函数可见。

当处理一个子目录、调用一个函数时，CMake创建一个新的作用域，其复制当前作用域全部变量，在子作用域中对变量的修改不会对父作用域产生影响。要修改父作用域中的变量，可以在set时指定特殊选项：

变量的值可以是一个列表，这样的变量可以被展开为多个值：

有些时候你可能期望用户通过CMake的UI输入一些变量的值， 这时变量必须作为缓存条目。当CMake运行时，它会向二进制目录输出缓存文件（Cache file），缓存文件中的变量值通过CMake的UI展示给用户。

使用这种缓存的目的之一是，存储用户的选项，避免重新运行CMake时，反复要求用户输入相同的信息。

option 命令可以创建一个Boolean变量（ON/OFF）并将其存储在缓存中：

用户可以通过UI设置USE_PNG的值，并且在未来这一值会保存在缓存中。使用CLion作为IDE时，可以在CMake窗口中点击Cache选项卡，查看或者编辑缓存条目：

除了option 命令之外，find_file 也可以用来创建缓存条目。为set 命令指定特殊参数，亦可：

缓存条目的另外一个目的是， 存储那些难以确定的关键变量，这些变量可能对用户不可见。通常这些变量是系统相关的，例如CMAKE_WORDS_BIGENDIAN 。这类值可能需要CMake编译并运行一个程序来确定，一旦确定，即缓存。

位于缓存中的变量具有一个属性指示它是否为“进阶的”（advanced），默认的CMake GUI隐藏进阶条目。要标记一个缓存条目为进阶的，可以：

某些情况下，你可能需要限制缓存条目的值范围在一个有限的集合中，这是可以设置条目的STRINGS 属性，提供值列表。在GUI中，这种条目的字段会展示为下拉列表：

即使变量存在于缓存，你仍然可以在CMakeLists中覆盖它（改变作用域中此变量的值）。只需要不带CACHE选项调用set命令，即可覆盖缓存中同名变量的值。

另一方面，一旦变量值已经缓存，你一般无法在CMakeLists中改变缓存的值（与上述覆盖是两回事）。也就是说，当缓存中有VARNAME时，set(VARNAME
ON CACHE BOOL ) 不会有任何作用。要强制改变缓存中的值并覆盖当前作用域的值，可以联合使用FORCE 和CACHE选项。

构建配置允许工程使用不同方式构建：debug、optimized或者任何其它标记。CMake默认支持四种构建配置：

依据生成器的不同，CMake处理构建配置的方式有所差异，CMake尽可能遵循底层本地构建系统的约定，这意味着使用Makefiles、VS时构建配置影响构建的方式有所不同：

1. VS支持构建配置的概念，在IDE中你可以选择Debug、Release配置，CMake只需要对接到VS的构建配置即可
2. Makefile默认同时（CMake运行时）只能有一种配置被激活。使用CMAKE_BUILD_TYPE 变量可以指定目标配置。如果此变量为空，则不给构建添加额外标记。如果此变量设置为上面四种构建配置之一，则相应的变量、规则——例如CMAKE_CXX_FLAGS_<CONFIGNAME> 被添加到compile
   line中。可以使用下面的方式来分别基于Debug、Release配置进行构建：
   Shell

   1 2 3

   # 创建工程目录的两个兄弟目录，CD到其中分别执行： ccmake ../project-DCMAKE_BUILD_TYPE:STRING=Debug ccmake../project-DCMAKE_BUILD_TYPE:STRING=Release

CMake由CMakeLists.txt驱动，此文件包含构建需要的一切信息。

除了用于分隔命令参数，其余空白符一律被忽略。反斜杠可以用来指示转义字符。

和普通编程语言一样，CMake支持条件、循环控制结构，同时支持子过程（macro、function）

在else、endif上重复条件，有助于if-else-endif匹配检查，特别是多层嵌套时。

CMake同样支持elseif：

条件命令支持受限的表达式语法，如下表所列：

CMake操作符优先级从高到底：

1. 括号分组：()
2. 前缀一元操作符：EXISTS、COMMAND、DEFINED
3. 比较操作符：EQUAL、LESS、GREATER及其变体，以及MATCHES
4. 逻辑非：NOT
5. 逻辑或于：AND、OR

此命令用于迭代一个列表，第一个参数是每次迭代使用变量的名称，其余参数为被迭代的列表

注意，在循环内部，你可以使用迭代变量构造另外一个变量的名字，例如${NAME_OF_${item}}

此命令用于基于条件的迭代：

此命令用于中断foreach/while循环。

CMake中的函数很类似于C/C++函数。你可以向函数传递参数，除了依据形参名外，你还可以使用ARGC 、ARGV 、ARGN 、ARG0 、ARG1 ...等形式，在函数内部访问入参。

函数内部是一个新作用域，类似于add_subdirectory生成的新作用域一样，函数调用前的作用域被拷贝并传递到函数内部，函数返回时，新作用域消失。

函数的第一个形参是函数的名称，其它参数构成传统的形参列表：

此命令拥有从函数中返回，或者在listfile命令中提前结束。

宏于函数类似，但是宏不会创建新的作用域。传递给宏的参数也不被作为变量看待，而是在执行宏前替换为字符串：

对于宏， ARGC、ARG0、ARG1等也可以使用。ARG0代表传递给宏的第一个参数。

CMake是一个不断进化的工具，随着新版本的推出，会不断有新的命令被加入。很多时候，我们需要检查当前CMake版本是否支持某些特性。

我们可以使用if命令判断某个命令是否可用：

或者直接检查CMake的版本：

另外，还可以声明要求的最低的CMake版本：

所谓模块，仅仅是存放到一个文件中，一系列CMake命令的集合。我们可以用include 命令将模块包含到CMakeLists.txt中。举例：

包含一个模块时，可以使用绝对路径，或者是基于CMAKE_MODULE_PATH的相对路径，如果此变量未设置，默认为CMake的安装目录的Modules子目录。

模块依据用途的不同可以分为：

由于某些原因，在版本升级后，CMake可能不提供完全的向后兼容。这意味着使用新版的CMake处理基于旧版本的CMakeLists.txt时会出现问题。CMake引入策略这一特性，帮助用户和开发者处理此向后兼容问题。

策略机制实现以下目标：

1. 既有的工程能够用任何比CMakeLists作者使用的、更新版本的CMake构建。用户不应该需要修改CMakeLists代码，但是可能出现警告信息
2. 新特性的修正，老接口的Bug修复应当被执行，而非因向后兼容性的要求而搁置
3. 任何对CMake的改变，会导致CMakeLists文件必须更改的，应当加以文档说明。每个这样的改变应当具有唯一的标识符以便查阅文档，改变仅在工程提示自己支持的情况下才启用
4. 最终将会移除向后兼容性的代码，不再支持古老版本的CMake。因此而构建失败的工程必须得到有价值的错误提示

CMake中的所有策略被分配一个CMPNNNN 形式的名称，其中NNNN是一个整数值编号。策略同时支持出于兼容性目的的旧行为，以及“正确的”新行为。每个策略包含出现动机、新旧行为的详细说明文档。

可以在工程中对每个策略进行配置，设置其值为NEW或者OLD，CMake将遵从测量设置，从而表现出不同的构建行为。

设置策略有几种方式，最简单的是设置策略为特定的CMake版本：cmake_policy(VERSION
2.6) 。这样所有2.6版本之前引入的策略都被标记为NEW，而2.6之后引入的策略则标记为“未设置”，以便产生警告信息。

注：cmake_minimum_required命令同样会设置策略，因此仅在需要定制子目录的策略时才以VERSION选项调用cmake_policy命令。

以SET选项调用cmake_policy可以明确的设置单个策略。以CMP0002为例，该策略的新行为要求所有逻辑目标具有全局独特的名字。下面的命令可以抑制存在重复目标名时的警告信息：

类Unix操作系统的系统库常常位于/usr/lib或者/lib目录。这些目录被链接器作为隐含的库搜索目录，因此find_library(M_LIB
m) 将从/usr/lib/libm.so定位到Math库。

问题是，某些平台会依据体系结构的不同，提供库的不同版本：

find_library命令名不知道各种体系结构特定的系统如何定义上面的目录规则，因此此命令可能找到不匹配的体系结构的库文件。

此问题的一个解决办法是让链接器自动寻找库所在目录（不使用link_directories或者指定绝对路径），不幸的是，此办法无法区分库的动态、静态版本。CMake实际使用的妥协做法是：

1. 存在于隐含库搜索目录中的库，且链接器支持类似-Bstatic的选项来指定使用静态库，使用-l选项传递库名称
2. 其它情况下，传递库绝对路径给链接器

共享库和可加载模块有利于重用：

1. 缩短compile/link/run周期
2. 共享库重新构建时，依赖于它的共享库/可执行文件甚至不需要重新构建
3. 减少磁盘和内存消耗，因为同一共享库只需要一份

相比静态库，共享库更像是可执行文件，大部分系统要求共享库上具有可执行权限。和可执行文件一样，共享库可以链接到其它共享库。

对于静态库来说，一个object文件是最小单元；而共享库（包括其依赖）本身是一个最小单元。链接器可以从静态库中挑出需要的object文件，但是对于共享库及其依赖的其它共享库，都需要存在。

共享库和静态库的另外一个不同是库的声明顺序，指定静态库时顺序很重要，因为大部分链接器仅仅遍历库列表一次来寻找符号，依赖其它静态库的静态库必须放在列表前面。

当决定在工程使用共享库时，开发者必须面对几个问题。

在大部分UNIX系统中，默认所有符号被导出。在Windows系统中，开发者必须明确告知编译器哪些符号被导入（使用符号时）/导出（创建符号时）

当从UNIX移植项目到Windows平台时，你可以：

1. 创建一个额外的.def文件，或者
2. 使用微软的C/C++语言扩展——__declspec(dllexport) 、__declspec(dllimport) 声明的符号分别被导出、导入

如果一个源文件在创建、使用一个库时都需要使用，则必须使用宏来处理。CMake在Windows下构建共享库（DDL）时，会自动定义宏${LIBNAME}_EXPORTS 。我们可以利用此宏：

这样，VTK_COMMON_EXPORT在UNIX中为空白；在Windows下构建共享库时为__declspec(dllexport)。

UNIX和Windows存在一个重要的和符号需求相关的差异：Windows上的DLL需要完全解析，也就是在创建时必须链接所有符号；而UNIX允许共享库在运行时从可执行文件或者其它共享库中获取符号。因而在UNIX中，CMake会给可执行目标一个标记，允许它被共享库调用。

另外一个需要提及的关于C++全局对象的陷阱是，加载或者链接了C++共享库的main函数，必须基于C++的编译器来链接，否则cout之类的全局对象可能在使用时尚未初始化。

由于链接到共享库的可执行文件必须在运行时能找到这些库，特殊的环境变量或者链接器标记必须被使用。

不同系统都提供了工具，用以查看可执行文件实际上使用的是哪个库：

1. UNIX系统的ldd 命令：显示可执行文件使用哪些库。在Mac
   OS X上使用otool
   -L
2. Windows系统的depends 程序，功能类似

在很多UNIX系统中，可以使用环境变量LD_LIBRARY_PATH 来告诉应用程序到哪里寻找库，而在Windows中，环境变量PATH 同时用来寻找DLL和可执行文件。CMake会默认把运行时库的路径信息存放到可执行文件中，因此前述环境变量并不必须。但是某些时候你可能需要关闭这个特性，设置CMAKE_SKIP_RPATH=false 即可。

使用共享库时，运行时加载的库，应当与链接时期望的库的“版本”一致，即功能上没有不兼容的变化。

如何识别这种变化并没有一致的规范，某些UNIX系统通过soname来版本化共享库，所谓soname就是在共享库名称后附加可选的数字后缀，例如libx.so.1。仅当共享库的接口发生不兼容变化时soname才改变，如果libx从1.0到1.9维持了一致性的接口，它们的soname应该一致。注意soname和文件名不是一回事，1.3版本的libx的文件名可能叫libx.so.1.3，但是它的soname可能是libx.so.1。

soname是共享库文件的一个头字段。当可执行文件和共享库链接时，共享库的soname也存放到可执行文件中，因此在运行时加载时，可执行文件可以根据soname来寻找版本匹配的共享库文件。

当安装libx库到系统时，可以建立符号链接libx.so
-> libx.so.1 ，当libx出现不兼容升级时，则修改前述符号链接，例如libx.so
-> libx.so.2 。这样，新的程序总是和最新的libx版本进行链接。另一方面，这种符号链接用法可以扩展为，将某个soname链接到特定文件，例如libx.so.1
-> libx.so.1.3 ，如果1.3版本有一个BUG在1.3.2中修复，可以修改前述符号链接为libx.so.1
-> libx.so.1.3.2 ，这样基于libx.so.1链接的可执行文件在获得BUG修复的同时，能够找到正确的共享库。

CMake支持这种基于soname的版本号编码机制，只要底层平台支持soname，可以设置共享库目标的属性：

设置上述属性后，安装共享库时会产生如下文件和符号链接：

如果仅指定两个版本号中的一个，那么另外一个自动与之相同。

软件通常被安装到和源码、构建树无关的位置上。CMake提供一个install 命令，来说明一个工程如何被安装。正确使用这个命令后：

1. 对于基于Makefile的生成器，用户只需要执行make
   install 或者nmake
   install 即可完成安装
2. 对于基于GUI的平台，例如XCode、VS，用户只需要构建INSTALL目标

对install的每一次调用都会指定某些安装规则，这些规则会依据命令调用的顺序被执行。

install命令提供了若干“签名”（类似于子命令），签名作为第一个参数传入，可用的签名包括：

前四个签名都用于创建文件的安装规则，需要安装的目标、目录、文件紧接着签名列出。其余和安装相关的信息，以关键字参数的形式附加，大部分签名支持以下关键字：

以此签名调用instal命令，以便构建过程中创建的库、可执行文件。详细调用格式为：

注意上面代码中关于文件分类的规则，把同属于共享库的.SO、.DLL分别划分到LIBRART、RUNTIME是有意的设计，因为Windows平台下，DLL通常和EXE存放在一个目录，这样才能确保DLL能够被找到并加载。下面的调用确保共享库目标mySharedLib产生的所有文件在所有平台上均安装到期望的位置：

很多工程可能需要安装与目标无关的任何文件，这时可以使用一般目的的FILES签名：

某些工程可能安装额外的助手程序——Shell脚本或者Python脚本。这时可以使用PROGRAMS签名。此签名和FILES一样，只是默认权限为755。

有时候我们需要安装包含了大量资源文件的整个目录，此时使用DIRECTORY签名：

拷贝文件到安装树下（Installation tree）不是安装过程的唯一内容，有时候需要执行特定的逻辑。这时可以使用SCRIPT或者CODE签名：

注意脚本不是在CMakeLists.txt处理过程中，而是在安装过程中执行，因而在脚本中不能访问CMakeLists.txt定义的变量。尽管如此，CMAKE_INSTALL_PREFIX 、CMAKE_INSTALL_CONFIG_NAME  、CMAKE_INSTALL_COMPONENT 会被设置为真实的安装前缀、构建配置、组件类型。

OS自带的、第三方提供的或者工程本身生成的共享库，是某些可执行文件能够运行的前提条件。由OS提供的自然不需要额外安装；工程本身产生的库由add_library命令说明，一般通过install命令安装到系统。需要额外考虑的是第三方库。

CMake提供两个模块，用于简化共享库的处理。

使用该模块的get_prerequisites() 函数，可以分析一个可执行文件的依赖。将可执行文件的路径传递给此函数，其会输出运行此文件必须的依赖库的列表，包括传递性依赖。该函数使用各平台上的Native工具：dumpbin（Windows）、otool（Mac）、ldd（Linux）进行依赖分析。

使用该模块的fixup_bundle() 函数，可以依据可执行文件的相对位置，拷贝和修复共享库（依赖）。

对于Mac的bundle应用，需要的共享库会被嵌入到bundle中，并调用install_name_tool生成一个自包含bundle。

对于Widnows，需要的共享库会被拷贝到exe所在目录，可执行文件运行时会自动寻找并加载。

要使用fixup_bundle()函数，首先安装某个可执行目标，然后创建一个可以在安装时执行的CMake脚本，在此脚本中调用：

CMake 2.6开始，支持在两个CMake工程之间导入导出目标。

导入目标这一机制，用于将项目外部的磁盘文件转换为逻辑的CMake目标。在调用add_executable、add_library命令时，传递IMPORTED 选项，即可定义导入目标。CMake不会为导入目标生成构建文件，导入目标仅仅用于便利的引用外部的可执行文件和库。

下面的例子定义了一个导入的可执行文件，仅仅将其作为命令调用：

下面的例子定义了一个导入的库，并与之链接：

尽管导入机制很有用，但是作为导入者来说，你必须知道目标在磁盘的位置。

使用导出机制，可以在提供目标文件的同时，提供一个文件，帮助其它工程导入。联合使用install(TARGETS) 和install(EXPORTS) 可以在安装目标的同时，把CMake文件也安装到机器上：

助手文件的内容可以是：

注意上面这个脚本依据自身位置动态计算出目标位置，即使移动安装目录，也不会失效。

其它工程只需要包含助手文件即可：

注意，单个助手文件可以容纳多个目标，甚至这些目标不在同一个目录中：

典型情况下，在第三方工程需要导入之前，当前工程已经构建并安装，因此导出一般是基于安装树的。

CMake直接从构建树导出 ，这样第三方工程可以参考构建树来导入，这样就可以避免安装当前工程了。

使用export 命令可以直接从构建树生成一个助手文件：

第三方工程可以include当前工程构建树下的myproj-exprots.cmake文件，其中包含导入generator需要的全部信息。

这种导出方式在交叉编译场景下可以用到。

系统探测，即检测在其上构建的系统的各种环境信息，是构建跨平台库或者应用程序的关键因素。

很多C/C++程序依赖于外部的库，然后在编译和链接一个工程时，如何找到已经存在的头文件和库并不会顺利。因为开发程序的机器，和构建并安装程序的机器中，库的安装位置可能不一样。CMake提供多种特性，辅助开发者把外部库集成到工程中。

与集成外部库相关的命令包括：find_library 、find_path 、find_program 、find_package 。对于大部分C/C++库，使用前两个命令一般足够和系统上已安装的库进行链接，这两个命令分别可以用来定位库文件、头文件所在目录。举例：

注意：

1. find_*命令总是会寻找PATH环境变量
2. find_*命令会自动创建对应的缓存条目（文件没找到的情况下值为VAR-NOTFOUND ），便于用户手工修改。这样即使CMake没有找到文件，用户还可以手工的修复

在跨平台软件中，应当避免使用平台特定的代码，例如：

这会降低代码的可移植性，每当需要支持新的系统，都要改变代码。即便非要使用宏，也最好使用基于特性，而不是基于系统的判断。可以改造上述代码为：

通过try_compile 、try_run 命令，CMake可以用来自动生成类似上面的HAS_***宏定义。这些命令编译/执行一小段代码，以探测系统特性：

如果编译成功，则CMake变量HAS_FOOBAR_FUNC为真。我们可以通过add_definitions 命令或者配置头文件（更好），来设置HAS_FOOBAR_FUNC为宏定义。

如果单纯的编译并不够，还需要获知探测代码的运行结果，可以使用：

运用上述命令的运行结果，可以根据字节序的不同来定制构建过程或者设置宏定义。对于较小的测试程序，可以不特定编写文件，使用file 命令即可：

在CMake/Modules中预定义了若干CMake用，可简化日常工作。这些宏常常需要查看当前CMAKE_REQUIRED_FLAGS 、CMAKE_REQUIRED_LIBRARIES 变量的值，以便添加额外的编译标记，或者链接以测试：

CMake提供find_package(Package
[version]) 命令来查找符合CPack包规则的软件包。

该命令可以在两个模式下运行：Module、Config。

在第一种模式下，它会依次扫描CMAKE_MODULE_PATH、CMake安装目录，尝试寻找到一个名称为Find<Package>.cmake 的查找模块（find-module）。如果找到这样的查找模块，则加载之，并调用其来寻找目标包的全部组件。查找模块针对特定包编写，它了解此包的全部版本，能找到包的库或者其它文件。CMake提供了很多常用的查找模块。如果Module模式下没有定位到串口模块，命令自动切换到Config模式（亦可明确调用该模式）。在该模式下，命令会寻找包配置文件（package
configuration file）：目标包提供的、一个名为<Package>Config[Version].cmake 或者<package>-config[-version].cmake 的文件。只要给出包的名称，命令就知道从何处寻找包配置文件，可能的位置是<prefix>/lib/<package>/<package>-config.cmake 。

CMake的内置查找模块，在找到包后，一般会定义一系列的变量供当前工程使用：

要传递参数给编译器，可以指定命令行，或者使用一个预先配置好的头文件。

调用add_definitions 命令，可以向编译器传递宏定义：

如果要细粒度的控制宏定义，可以设置目录、目标、源文件的COMPILE_DEFINITIONS 属性：

这种方式更可维护，大部分工程应当使用该方式。应用程序只需要引入预先配置好的头文件即可，不必编写复杂的CMake规则。

我们可以把头文件看作一种配置文件，而要生成配置文件，可使用configure_file(input
output [@ONLY]) 命令，此命令需要一个“输入文件”，输入文件可以包含三种变量定义方式：

配置文件应当输出到二进制树，而不是源码树，避免代码污染。因为单个CMake的源码树可以供多种构建树或平台使用，它们生成的配置文件常常是不一样的。你可能需要用include_directories命令将配置文件所在目录作为头文件目录。

除了头文件以外，configure_file 命令亦可用来生成包的配置文件。在“查找包”一节我们已经讨论过，包配置文件供其它工程发现本包。

很多时候，“构建”一个工程不仅仅是简单的编译、链接、拷贝，额外的工作——例如利用文档工具生成文档—— 需要在构建过程中完成。

通过定制命令和目标，CMake可以被扩展以支持任意的任务（或者说规则）。

定制命令时，面临的一个重要问题是可移植性：

1. 各平台上用于完成一项任务的工具不同，以复制文件为例，UNIX使用cp命令，Windows则使用copy命令
2. 目标在各平台上的名字不同，例如库x在UNIX上可能叫libx.so，Windows上则叫x.dll

CMake提供了两个主要工具，解决上面两个可移植性问题。

使用cmake
-E arguments 调用，可以执行一些跨平台的操作，在CMakeLists.txt中可以通过定制命令来调用cmake命令，cmake这个可执行文件可以用变量CMAKE_COMMAND 引用。

支持的操作（arguments）包括：

CMake不限制你仅使用cmake命令，事实上你可以使用任何命令，但是要注意可移植性问题。一个通用的实践是，通过find_program 找到一个程序，然后在定制命令中调用之。

CMake提供了一系列预定义的变量，描述系统的特征：

add_custom_command有两个主要的签名：TARGET、OUTPUT，分别用于为目标或者文件添加额外的规则。其中TARGET签名语法如下：

下面是一个例子，在目标构建好后立即拷贝之：

add_custom_command的另外一个用途是指定生成一个文件的规则。这种情况下，已有的用于生成目标文件的规则被替换掉。语法如下：

在某些库的构建过程中，例如TIFF，会先编译并构建一个可执行文件，再用此可执行文件生成还有系统特定信息的源码，而此源码参与库的最终构建。这种场景下，可以使用add_custom_command来生成源码。

CMake支持除了库、可执行文件之外的，更一般概念上的目标，称为定制目标。生成文档、运行测试、更新Web服务器都可以抽象为目标。

要添加定制目标，需要调用下面的命令：

所谓交叉编译，就是指软件在一个平台（Build host）上构建，而在另外一个平台（Target Platform）上运行。目标平台往往是另外一个OS甚至没有OS，也常常使用与构建平台不一样的硬件，这导致目标平台根本不能运行开发环境。交叉编译的典型应用是嵌入式开发，程序需要在路由器、传感器之类的特殊硬件上运行。

交叉编译依赖于工具链。工具链是针对目标平台的一整套工具，包括编译器、链接器，以及目标平台的全套头文件、库。

从2.6开始，CMake完整的支持交叉编译，包括Linux-Windows交叉编译，或者PC-嵌入设备交叉编译。在交叉编译场景下，会面临以下问题：

1. CMake无法自动的检测目标平台
2. CMake无法在默认系统目录寻找库、头文件
3. 构建出来的可执行文件无法运行

CMake区分构建平台、运行平台的信息，让给用户可以解决交叉编译相关的问题，避免例如运行虚拟机的额外需求。

通过一个所谓工具链（Toolchain）文件，我们可以告知CMake关于目标平台的任何必要信息。CMakeList.txt必须被调整以适应目标平台和构建平台具有不同属性的情况。下面是一个Linux下基于MinGW交叉编译器，交叉编译Windows程序使用的工具链文件：

通过下面的命令，可以指示CMake使用上述工具链文件：

CMAKE_TOOLCHAIN_FILE必须在最初运行时设置，后续其值会保存为缓存条目。每个目标平台一般只需要一个工具链文件。

在工具链文件中，可能需要设置以下变量：

注：形如CMAKE_SYSTEM_XXX的变量，总是在描述目标平台。如果要描述当前构建平台，可以使用相应的CMAKE_HOST_SYSTEM_XXX变量。

CMake提供了一些变量，用于粗粒度的测试系统特征：

1. 目标平台类型指示变量：UNIX、WIN32、APPLE
2. 构建平台类型指示变量：CMAKE_HOST_UNIX、 CMAKE_HOST_WIN32、CMAKE_HOST_APPLE

更加细化的测试变量，可以使用上节提到的CMAKE_SYSTEM_XXX、CMAKE_HOST_SYSTEM_XXX变量。

CMake中使用CHECK_INCLUDE_FILES、CHECK_C_SOURCE_RUNS等宏来测试平台属性，这些宏通常使用try_compile、try_run命令。

try_run无法正常运行，因为交叉编译出的可执行文件不能在构建平台上运行。try_run被调用时，它首先尝试编译，如果成功它会检查CMAKE_CROSSCOMPILING变量，该变量为真的话它不会尝试运行，而是设置两个缓存变量，供用户后续修改。考虑下面这个例子：

如果SharedLPathInfo.cxx编译成功，SHARED_LIBRARY_PATH_INFO_COMPILED被设置为真。而交叉编译时无法运行可执行文件，因此CMake创建一个缓存条目：SHARED_LIBRARY_PATH_TYPE=PLEASE_FILL_OUT-FAILED_TO_RUN ，该条目必须被手工的设置为SharedLPathInfo的在目标平台上的退出码。如果指定了OUTPUT_VARIABLE选项，CMake还会创建一个缓存条目SHARED_LIBRARY_PATH_TYPE__TRYRUN_OUTPUT=PLEASE_FILL_OUT-NOTFOUND ，该条目必须手工设置为SharedLPathInfo在目标平台上的标准输出/错误。要手工运行，可以考虑构建目录下的cmTryCompileExec-SHARED_LIBRARY_PATH_TYPE 到目标平台下执行。除了设置缓存条目外，还可以把运行结果记录到${CMAKE_BINARY_DIR}/TryRunResults.cmake 中，该文件由CMake自动创建，其中包含所有CMake无法确定的变量，并记录可执行文件位置、源码位置、运行参数等信息。我们可以根据运行结果填充这些变量的值，然后为cmake调用缓存：

本节示例一个完整的交叉编译的过程。

交叉编译的第一步是寻找合适的工具链，如果你已经安装好工具链，则可以跳过这一步。

不同工程——包括基于Linux的PDA和嵌入式设备厂商的——在Linux上处理交叉编译的途径不同，它们有自己的构建流程和工具链。CMake可以使用这些工具链，只要它们是基于普通文件系统的。

一个提供较为完整的目标平台环境的工具链套件是Embedded Linux Development Toolkit（ELDK），该套件支持ARM、PowerPC、MIPS等目标平台。ELDK或者其它工具链可以被安装在构建平台的任意位置，例如：

下载并安装好工具链后，下一步就是编写工具链文件，注意我们在上面提到过，每个工具链只需要一个这样的文件：

工具链文件可以存放在任何地方，推荐将其存放在统一的目录，方便其它工程重用。

不但支持具有OS的目标平台的交叉编译，CMake还可以针对那些没有OS的微控制器进行交叉编译。

本节的例子使用SDCC编译器，该编译器可以运行于主流系统下，支持8/16位微控制器的交叉编译。

首先，还是编写工具链文件：

对于没有OS的目标平台，其系统名称设置为Generic。CMake假设Generic平台不支持共享库。

很多微控制器工程不需要依赖任何外部库，因此往往不需要设置影响find_**的变量。

CMakeLists文件：

执行构建：