CMake(一)：系统学习CMake之初识CMake

1. 建立一个项目

​如果没有构建系统，项目只是文件的集合。CMake为这一点带来了一些秩序，首先是一个可读的文件CMakeLists.txt，它定义了应该构建什么，如何构建，运行什么测试，创建什么包。这个文件是对整个项目的独立于平台的描述，然后CMake将其转换为特定于平台的构建工具项目文件。

​CMake的一个基本概念是项目既要有source directory又要有binary directory。

​source directory是CMakeLists.txt文件所在的位置，项目的源文件和构建所需的所有其他文件都组织在该位置下。源目录通常使用git、subversion或类似工具进行版本控制。

​binary directory是创建build生成的所有内容的地方。它通常也被称为build directory。CMake通常使用术语build directory，但在开发人员中，术语 build directory更常用。CMake，选择的构建工具(例如，make, Visual Studio等)，CTest和CPack都将在build directory及其下的子目录中创建各种文件。可执行文件、库、测试输出和包都是在构建目录中创建的。CMake还在构建目录中创建了一个名为CMakeCache.txt的特殊文件，用于存储各种信息，以便在后续运行时重用。开发人员通常不需要关心CMakeCache.txt文件。构建工具的项目文件(例如Xcode或Visual Studio项目文件，Makefiles等)也在构建目录中创建，并不打算将其置于版本控制之下。txt文件是项目的规范描述，生成的项目文件应该被视为构建输出的一部分。

​当开发人员开始一个项目时，他们必须决定他们的构建目录与源目录的关系。基本上有两种方法:源内构建和源外构建。

1.1 源内构建

​source directory和build directory可能是相同的，尽管不鼓励这样做。这种安排称为源内构建。开发人员在职业生涯的开始阶段通常会使用这种方法，因为他们认为这种方法很简单。然而，源代码构建的主要困难在于，所有的构建输出都与源文件混在一起。这种分离的缺乏导致目录与各种文件和子目录混杂在一起，使得管理项目源文件变得更加困难，并存在构建输出覆盖源文件的风险。它还使版本控制系统的工作更加困难，因为构建过程中创建了许多文件，源代码控制工具必须知道要忽略这些文件，或者开发人员必须在提交过程中手动排除这些文件。源内构建的另一个缺点是，清除所有构建输出并使用干净的源代码树重新开始可能不容易。由于这些原因，即使是简单的项目，也不鼓励开发人员尽可能地使用内源构建。

1.2 源外构建

​更可取的安排是使源目录和构建目录不同，这称为外部构建。这使得源代码和构建输出彼此完全分离，从而避免了内部源代码构建所经历的混合问题。外包构建还有一个优势，开发人员可以为同一个源目录创建多个构建目录，这允许构建使用不同的选项集，比如调试和发布版本，等等。

​一些开发人员使用的另一种方法是将构建目录作为源目录的子目录。这提供了源外构建的大部分优点，但它仍然带有源内安排的一些缺点。除非有很好的理由这样构造，否则建议将构建目录完全保留在源代码树之外。

1.3 生成的项目文件

​一旦选择了目录结构，开发人员就运行CMake，它读取CMakeLists.txt文件，并在构建目录中创建项目文件。开发人员通过选择特定的项目文件生成器来选择要创建的项目文件的类型。支持一系列不同的生成器，下表中列出了更常用的生成器。

目录	Generator	Multi-config
Visual Studio
	Visual Studio 15 2017	Yes
	Visual Studio 14 2015
	...
Xcode	Xcode	Yes
Ninja	Ninja	No
Makefiles
	Unix Makefiles	No
	MSYS Makefiles
	MinGw Makefiles
	NMake Makefiles

​有些生成器生成支持多种配置的项目(例如,Debug,Release等)。这使得开发者可以在不需要重新运行CMake的情况下选择不同的构建配置，而CMake更适合于生成器在诸如Xcode和Visual Studio这样的IDE环境中创建项目。对于不支持多个配置的生成器，开发人员必须重新运行CMake，在调试、发布等版本之间切换构建。它们更简单，并且通常在IDE环境中与特定编译器(Qt Creator、KDevelop等)没有那么紧密联系的环境中有很好的支持。

​运行CMake最基本的方法是通过CMake命令行工具。调用它的最简单的方法是更改构建目录，并向cmake传递关于源树的生成器类型和位置的选项。例如:

mkdir build
cd build
cmake -G "Unix Makefiles" ../source

​如果省略了-G选项，CMake将根据主机平台选择默认的生成器类型。对于所有类型的生成器，CMake将执行一系列的测试并询问系统以确定如何设置项目文件。这包括诸如验证编译器工作，确定支持的编译器特性集和各种其他任务。在CMake成功完成之前，各种信息将被记录下来，如下所示:

​上面强调了项目文件的创建实际上涉及两个步骤;配置和生成。在配置阶段，CMake读取CMakeLists.txt文件，并构建整个项目的内部表示。完成这些之后，生成阶段将创建项目文件。配置和生成之间的区别对于基本的CMake使用来说并不重要，但是在后面的章节中，配置和生成的分离变得很重要。

当CMake完成运行后，它会在构建目录中保存一个CMakeCache.txt文件。CMake使用这个文件来保存详细信息，这样如果它再次运行，它可以重用第一次计算的信息，并加快项目的生成。它还允许在运行之间保存开发人员选项。一个GUI应用程序，cmake- GUI，可以作为运行cmake命令行工具的另一种选择，变量，在那里它的实用性更加明显。

1.4 运行构建工具

​此时，随着项目文件的可用，开发人员可以以他们习惯的方式使用他们所选择的构建工具。构建目录将包含必要的项目文件，这些文件可以加载到IDE中，通过命令行工具读取，等等。或者，cmake可以代表开发者调用构建工具，如下所示:

cmake --build /some/path/build --config Debug --target MyApp

​–build选项指向CMake项目生成步骤所使用的构建目录。对于多个配置生成器，–config选项指定要构建哪个配置，而单个配置生成器将忽略–config选项，而是依赖于执行CMake项目生成步骤时提供的信息。可以使用–target选项告诉构建工具要构建什么，或者如果省略，将构建默认目标。

​虽然开发人员通常会在日常开发中直接调用他们选择的构建工具，但通过上面所示的cmake命令调用它在驱动自动构建的脚本中可能更有用。使用这种方法，一个简单的脚本构建可能看起来像这样:

mkdir build
cd build
cmake -G "Unix Makefiles" ../source
cmake --build . --config Release --target MyApp

​如果开发人员希望使用不同的生成器进行试验，所需要做的就是更改给-G CMake选项的参数，然后将自动调用正确的构建工具。构建工具甚至不需要在用户的PATH上，cmake --build就可以工作(尽管在第一次调用cmake时，它可能需要在初始配置步骤中)。

更多请关注微信公众号【Hope Hut】：