目录

一.环境准备

1.1.Cmake安装

1.2. VSCodeCMake插件安装

1.3 快速样例-helloworld⼯程

二. cmake的基础命令⾏使用示例

2.1.文件准备

2.2.⽣成构建系统

2.3.编译连接

2.4.测试Ctest模块

2.5.测试安装模块

2.6.测试打包模块

2.7 查看帮助

---

CMake语法简洁清晰，易于上手，同时功能强大而灵活，在现代C/C++开发中应用极为广泛。其卓越的跨平台能力和高度的IDE支持，使其已成为C/C++领域事实上的构建标准与工程管理的核心工具。

掌握CMake不仅能够让你的项目结构更加清晰、构建过程更加高效优雅，还能极大地简化跨平台开发的复杂度，提升项目的可维护性和协作效率。无论是管理个人项目还是参与大型企业级开发，精通CMake都是一项极具价值的关键技能，必将显著提升你的工程实践能力和职场竞争力。

一.环境准备

1.1.Cmake安装

ubuntu安装

sudo apt install cmake
cmake --version

在不同 Linux 发行版中，软件仓库内预装的 CMake 版本通常会随着系统版本的更新而逐步升级。新发布的系统版本往往提供更新的 CMake，以支持更多现代特性和改进。以下是常见发行版与 CMake 版本的对应情况概览，可供环境准备时参考：

Linux 发行版	发行版版本	预装/默认 CMake 版本	是否满足本专栏要求（≥3.18）	备注
Ubuntu LTS	22.04 (Jammy)	3.22	是	需通过 apt 安装
	24.04 (Noble)	3.28+	是	默认版本较高，功能更全面
Debian	12 (Bookworm)	3.22	是	包管理器直接安装
Fedora	39	3.28+	是	版本较新，支持新特性
CentOS Stream	9	3.22+	是	需从默认仓库安装
Arch Linux	滚动更新	最新稳定版（如3.28+）	是	持续更新，支持最新功能

本专栏所使用的 CMake 功能需要最低版本为 3.18。若您当前系统中的版本低于此要求，建议通过包管理工具安装官方软件源中的新版本，或从CMake官网下载预编译二进制包进行安装，亦可从源码编译安装，以保证课程实验的顺利进行。

1.2. VSCodeCMake插件安装

VSCodeCMake插件有以下2点好处：

1. 语法⾼亮和代码补全：对 CMakeLists.txt ⽂件提供语法⾼亮显⽰，使代码结构更加清晰易 读。同时，⽀持代码补全功能，当你输⼊CMake命令或变量时，插件会⾃动提⽰可能的选项，减 少⼿动输⼊的错误和时间。
2. 智能分析和错误检查：能够对 CMakeLists.txt ⽂件进⾏智能分析，检查其中的语法错误和潜 在问题，并在编辑器中实时显⽰错误提⽰和警告信息，帮助你及时发现和解决问题。

安装步骤如下：

Step 0：打开VSCode，点击左侧活动栏中的扩展图标（或按 Ctrl+Shift+X ）。

Step 1：在搜索框中输⼊ CMake ，我们选择安装以下4个插件：

1. CMake
2. CMake Tools
3. CMake LanguageSupport
4. CMake IntelliSence

Step 2：挨个点击Install按钮，安装完成并且成功之后如下图

1.3 快速样例-helloworld⼯程

本节我们将使⽤⼀个例⼦来演⽰下使⽤CMake构建⼀个最简单的C++程序，⼤致了解下CMake的 使⽤⽅式。

我们创建⼀个新的 hello_world ⼯程。

下图展⽰了使⽤CMake来管理helloworld程序⽣成的过程

main.cc

#include<iostream>
using namespace std;
int main()
{std::cout<<"Hello World"<<std::endl;
}

Cmakelists.txt

# 1 设置能运行此工程的CMake最低版本要求
# 此处指定构建本项目所需CMake的最小版本为3.18，若环境中的版本低于此值，配置阶段将报错
cmake_minimum_required(VERSION 3.18)# 2 设置项目名称
# 定义工程名为“helloWorld”，CMake会自动生成一些与该名称相关的变量，如 PROJECT_NAME、PROJECT_SOURCE_DIR 等
project(helloWorld)# 3 添加构建目标（可执行文件）
# 指定生成一个名为“main”的可执行文件，该文件由源文件 main.cc 编译链接而成
add_executable(main main.cc)

为什么需要设置最低 CMake 版本？

CMake 作为一个持续演进的构建工具，其版本迭代显著（目前主流已进入 4.x 系列，历史版本以 3.x 为主）。不同版本往往会引入新的语法、命令、模块，甚至对现有命令的行为做出调整。如果项目中使用了某些高版本才支持的功能——例如新的内置函数、生成器表达式或特定目标属性——而用户本地安装的 CMake 版本过低，则可能无法正确解析工程配置，导致难以诊断的错误或无法预料的行为。

为避免此类兼容性问题，CMake 提供了 cmake_minimum_required 命令。该命令在配置阶段（即执行 cmake 命令时）首先检查当前环境中 CMake 的版本：

• 若当前版本低于指定的最低要求，CMake 会立即终止处理过程，并报错提示用户“需要至少某个版本”，从而防止因语法或功能不兼容导致的后续问题；

• 只有在版本符合要求时，CMake 才会继续执行后续的配置流程，确保工程按预期正确配置。

这样的机制显著提高了构建脚本的可移植性和可靠性，是实现跨版本兼容的重要保障。

什么是 CMake 中的“目标”？

在 CMake 中，“目标（Target）”是一个核心概念，代表构建过程中要生成的输出实体，例如可执行文件、静态库或动态库。每个目标都封装了构建该实体所需的全部信息，包括源文件、编译选项、链接依赖和安装规则等。

“目标”可类比于传统 Makefile 中的构建目标，但其功能更为强大和结构化。在现代 CMake 的实践中，以目标为中心的工程管理方式被广泛推荐。通过明确定义目标及其属性，开发者可以更清晰、更模块化地组织项目结构，精确控制构建过程，并有效管理依赖关系。正因如此，理解并熟练使用“目标”，是掌握现代 CMake 构建方法的关键一步，我们将在课程的后续章节中对其作深入探讨。

---

运⾏cmake

# 运⾏ CMake 命令 就在这⼀步⽣成Makefile 
cmake .

我们看到cmake直接生成了makefile

有了makefile，那后续的工作大家肯定知道了吧

二. cmake的基础命令⾏使用示例

接下来我将举一个比较全面的例子。

我们接下来将介绍cmake的基础命令⾏，介绍了如何⽣成构建⽂件，编译链接，安装等。

2.1.文件准备

mkdir cmake_tools
cd cmake_tools
touch main.cpp test.cpp CMakelists.txt 

main.cpp

#include <iostream>
int main()
{std::cout << "hello world!" << std::endl;return 0;
}

test.cpp

#include<iostream>
#include<assert.h>
int main()
{assert(1+2==3);std::cout<<"test OK"<<std::endl;
}

CmakeLists.txt

# 1 设置能运行此cmake 工程的最低cmake版本要求
# 指定构建本项目所需的最低CMake版本为3.18，确保使用的CMake特性得到支持
cmake_minimum_required(VERSION 3.18)# 2 设置项目名称
# 定义项目名称为"helloWorld"，CMake会自动创建相关变量如PROJECT_NAME
project(helloWorld)# 3 添加构建目标
# 创建一个名为"main"的可执行文件，由main.cpp源文件编译而成
# 相当于执行: g++ main.cpp -o main
add_executable(main main.cpp)# 创建另一个名为"testAdd"的可执行文件，专门用于测试
# 由test.cpp源文件编译而成，通常包含单元测试代码
add_executable(testAdd test.cpp)# 4 开启测试功能 & 集成测试逻辑
# 包含CTest模块，为项目添加测试支持功能
include(CTest)
# 添加一个名为"Case_Add"的测试用例
# 该测试通过运行专门编译的测试程序"testAdd"来执行
add_test(NAME Case_Add      # 测试用例的名称，用于标识和报告COMMAND testAdd    # 测试命令：运行测试可执行文件testAdd
)# 5 安装二进制可执行程序到本地
# 包含GNUInstallDirs模块，提供标准安装目录的定义
include(GNUInstallDirs)
# 安装主程序目标"main"到默认安装目录
# 默认情况下会安装到CMAKE_INSTALL_BINDIR（通常为bin目录）
install(TARGETS main)# 6 开启打包功能 & 打包二进制可执行程序
# 包含CPack模块，为项目添加打包功能
include(CPack)
# CPack会自动收集所有通过install命令指定的目标
# 并将它们打包到一个可分发的压缩包中（如ZIP、TGZ等格式）
# 使用cpack命令即可执行打包操作

2.2.⽣成构建系统

通过 cmake 可以看到cmake命令⽀持的详细参数，常⽤的参数如下：

在 CMake 中，-S 和 -B 是两个常用的命令行参数，用于明确指定项目的源目录和构建目录。

-S 参数用于指定源代码的根目录，该目录下必须包含一个顶层的 CMakeLists.txt 文件。这个源文件目录代表了项目的“源文件树”（Source Tree），即整个项目源代码的目录结构，CMake 正是通过该目录中的 CMakeLists.txt 文件来识别和配置项目。

-B 参数用于指定构建目录，即构建过程中生成的中间文件（如目标文件、依赖信息等）和最终输出文件（如可执行文件、库文件）的存放路径。这个构建目录被称为“构建树”（Build Tree），与源文件树分开，以保持源代码的整洁。构建目录中通常会生成一个 CMakeCache.txt 文件，用于缓存CMake的配置变量，从而避免每次配置时重复检测系统环境。

使用 -S 和 -B 参数是一种推荐的做法，它能够清晰地将源代码与生成的文件分离，既便于管理，也支持为不同构建配置（如Debug、Release）创建多个独立的构建目录。

---

在 CMake 构建过程中，根据构建生成的中间文件存放位置的不同，可分为两种构建方式：源内构建与源外构建。

1.源内构建（In-Source Build）

指在包含顶层 CMakeLists.txt 的源代码目录中直接进行构建。此时，生成的所有中间文件和最终目标文件都会与源代码混杂在同一目录中。使用方式如下：

cmake .

该命令表示在当前目录（即源代码根目录）中进行配置和生成构建系统。由于构建文件与源代码混合存放，容易造成结构混乱，因此通常不推荐使用该方式。

2.源外构建（Out-of-Source Build）

指在一个独立于源代码的专门目录（通常命名为 build）中进行构建。这样做可以确保所有构建过程中产生的文件（包括中间文件、缓存文件和目标文件）与源代码完全分离，保持源代码树的整洁。使用方式如下：

mkdir build && cd build
cmake ../

该命令首先创建并进入一个名为 build 的子目录，然后在该目录中执行 CMake，并通过 ../ 指定上一级目录（即源代码根目录）作为源文件路径。此时，build 为构建目录，../ 为源文件目录。

源外构建是 CMake 官方推荐的最佳实践。它不仅可以保持源代码的纯净，还支持同时维护多个不同配置（如 Debug 与 Release）的构建目录，极大提高了项目管理的灵活性和可维护性。

---

接下来我们将详细讲解下面这3个命令的用法。

用法一： cmake [options] <path-to-source>

cmake [options] <path-to-source>

• 此命令在当前工作目录中运行 CMake，并将其作为构建目录。

• 参数 <path-to-source> 用于指定包含顶级 CMakeLists.txt 文件的源代码目录。

• 执行后，CMake 会在当前目录生成所有的构建系统文件（如 Makefile）。

我们来看看

用法二：cmake [options] <path-to-existing-build>

• 含义：此命令用于重新配置一个已经生成过的构建目录。

• 参数 <path-to-existing-build> 是一个已经执行过 CMake 的构建目录的路径。

• 使用场景：当你修改了源代码目录中的 CMakeLists.txt 文件或其他配置，需要重新生成构建系统时，使用此命令非常方便。它会在原有配置的基础上应用最新的变更。

假设你后来修改了/root/cmake/cmake_tools/CMakeLists.txt 文件，需要重新生成构建系统时使用。

事实上，下面这个命令大有来头

cmake .

cmake . 中的点号 . 在Linux/Unix系统中代表当前目录。

所以，这个命令的意思是：告诉CMake，以当前所在的目录（/root/cmake/build）作为构建目录（Build Directory），并且以当前目录（/root/cmake/build）也作为源代码目录（Source Directory）。

为什么这次运行 cmake . 没有报错？

因为你所在的 build 目录里已经存在一个由第一次CMake运行生成的 CMakeCache.txt 文件。这个缓存文件记录了你最初的配置（包括源代码的实际路径在哪里）。所以当CMake再次在当前目录运行时，它读取了这个缓存，知道了真正的源代码目录在哪里，从而能够成功完成配置。

我们仔细寻找

在他里面我们找到了这个

这个CMAKE_HOME_DIRECTORY:INTERNAL=/root/cmake/cmake_tools，不就是我们源代码的目录吗？

用法三：cmake [options] -S <path-to-source> -B <path-to-build>

• 含义：这是现代 CMake 推荐使用的命令格式。通过 -S 选项显式指定源代码目录的路径，通过 -B 选项显式指定构建目录的路径。

• 优势：

  • 清晰分离：明确将源代码（只读）和构建产物（可随时清理）放在不同的目录中，结构清晰。

  • 自动创建：如果 -B 指定的构建目录不存在，CMake 会自动创建它，无需手动建立。

  • 通用性好：命令格式统一，易于记忆和脚本化。

接下来我们演示第3种方式

2.3.编译连接

⽣成构建⽂件以后，就可以使⽤cmake来编译链接，也可以使⽤第三⽅构建系统进⾏。

因为⽣成的makefile就在构建树的根⽬录下，所以可以直接在此⽬录运⾏make。

cmake --build ./
或者
make 

2.4.测试Ctest模块

正常我们在编写功能代码之后，也会编写对应的单元测试代码，然后使⽤ctest来调⽤我们的单元测 试。

如果cmake的配置⽂件CMakeLists.txt⾥包含CTest功能，则⽣成的makefile⾥也会包含test伪⽬标， 可以使⽤make来执⾏。

我们的CMakeLists.txt⾥就刚好包含了CTest功能。

第1行：include(CTest)

• 这是什么？：这是一个指令，用于包含（启用）CMake 的 CTest 模块。

• 它做了什么？

  1. 启用测试功能：它告诉 CMake：“本项目需要进行测试”。CMake 会因此生成必要的构建目标（如 make test）和文件（如 CTestTestfile.cmake）。

  2. 提供管理能力：它解锁了一系列与测试相关的高级功能，比如：批量运行所有测试、生成详细的测试报告、处理测试之间的依赖关系、与持续集成（CI）系统（如 Jenkins, GitLab CI）无缝集成。

简单来说：include(CTest) 就是打开你项目的“测试总开关”。

第2-7行：add_test(...)

• 这是什么？：这是一个指令，用于注册一个具体的测试用例到 CTest 框架中。

• 它做了什么？：它创建了一个名为 Case_Add 的测试项，并规定这个测试的运行方式就是执行 testAdd 这个命令。

让我们分解它的参数：

• NAME Case_Add：

  • 这是测试用例的唯一标识符。CTest 在输出报告时会使用这个名字。

  • 例如，你会看到 Passed: Case_Add 或 Failed: Case_Add，这比看到“第1个测试”清晰得多。

  • 你可以（也应该）添加多个 add_test 指令，每个都有描述性的名字（如 Case_Subtract, FunctionA_InvalidInput_Test）。

• COMMAND testAdd：

  • 这是测试的核心——规定运行什么命令来执行测试。

  • 这里的 testAdd 就是你之前通过 add_executable(testAdd test.cpp) 编译出来的测试可执行文件的名称。

  • CTest 会运行这个命令，并根据它的退出状态码（Exit Code）来判断测试是否通过：

    • 返回 0：CTest 认为测试通过 (PASS)。

    • 返回非 0：CTest 认为测试失败 (FAIL)。

---

我们来看看怎么使用

ctest
或者
make test

上面是测试成功的情况。

测试失败的情况

我们回去把test.cpp修改成下面这样子

#include<iostream>
#include<assert.h>
int main()
{assert(1+2==4);std::cout<<"test OK"<<std::endl;
}

我们发现它报错了

我们运行Ctest模块看看

错误信息解读

1. 测试结果摘要：

   0% tests passed, 1 tests failed out of 1

   这很清楚：总共运行了1个测试，全部失败了，成功率为0%。

2. 失败详情：

   1 - Case_Add (Subprocess aborted)

   具体是名为 Case_Add 的测试失败了，失败原因是：子进程异常中止 (Subprocess aborted)。

3. 关键线索：

   Output from these tests are in: /root/cmake/build/Testing/Temporary/LastTest.log

   这告诉你：详细的错误信息已经写入了一个日志文件中。

我们可以去这个日志里面看看

这个和我们手动运行的结果基本上是一样的啊！！

 CTestTestfile.cmake文件

我们这里需要知道Ctest与CTestTestfile.cmake文件有关

简单来说，CTestTestfile.cmake 是 CTest（CMake 的测试工具）的“测试清单”或“测试剧本”。它由 CMake 自动生成，其唯一目的是告诉 ctest 命令在这个特定的目录下有哪些测试需要运行以及如何运行。

2.5.测试安装模块

在单元测试通过之后，我们可以使⽤cmake的安装命令把库和⼆进制发布到本机的标准路径，供 ⼤家⼀起开发使⽤。

如果cmake的配置⽂件CMakeLists.txt⾥包含install函数，则⽣成的makefile⾥也 会包含install伪⽬标，可以使⽤make来执⾏。

这两行代码的目的是：定义一个规则，告诉 CMake 如何将编译好的可执行文件 main “正式安装”到您系统的标准目录中，使其成为一个可以被系统识别和全局使用的程序。

您可以把它理解为软件开发的“发布”或“装机”步骤。它完成了从“编译成功”（程序在构建目录里能用）到“安装就绪”（程序在系统目录里，任何地方都能用）的转变。

第1行：include(GNUInstallDirs)

• 这是什么？：这是一个包含（include）指令，它告诉 CMake 去加载一个名为 GNUInstallDirs 的内置模块。

• 为什么需要它？：不同的操作系统（甚至不同的 Linux 发行版）对于“应该把可执行文件装在哪”、“库文件装在哪”、“头文件装在哪”都有自己的惯例和标准。GNUInstallDirs 模块定义了一组跨平台的 CMake 变量，这些变量自动指向当前系统遵循这些惯例的正确路径。

• 它提供了哪些重要变量？

  • CMAKE_INSTALL_BINDIR：通常指向 bin 目录，用于安装用户可执行程序（如 main）。

  • CMAKE_INSTALL_SBINDIR：通常指向 sbin 目录，用于安装系统管理员的可执行程序。

  • CMAKE_INSTALL_LIBDIR：通常指向 lib 或 lib64，用于安装库文件（.so, .a）。

  • CMAKE_INSTALL_INCLUDEDIR：通常指向 include，用于安装头文件（.h）。

  • 默认的安装前缀（CMAKE_INSTALL_PREFIX）通常是 /usr/local。所以，CMAKE_INSTALL_BINDIR 的完整路径通常是 /usr/local/bin。

简单来说：include(GNUInstallDirs) 就是让 CMake 帮你搞清楚各个类型的文件在该系统上应该装在哪，你不用自己去硬编码路径，保证了移植性。

第2行：install(TARGETS main)

• 这是什么？：这是一个安装（install）指令，它指定了要安装的目标（Target）。这里的 main 就是你之前通过 add_executable(main main.cpp) 定义的那个可执行文件目标。

• 它会做什么？

  1. 生成安装规则：CMake 会在生成的构建系统（如 Makefile）中创建一条 install 规则。

  2. 指定安装位置：因为你没有明确指定安装到哪里，CMake 会使用默认的安装位置。对于可执行文件目标（add_executable 添加的），默认位置就是 GNUInstallDirs 模块提供的 CMAKE_INSTALL_BINDIR（即 <prefix>/bin）。

---

我们现在来看看怎么来进行安装

sudo cmake --install .
或者
sudo make install

现在这个main程序就被安装到这个/usr/local/bin目录里面了，我们也可以看看是什么情况

甚至，我们可以像下面这样子执行这个文件

现在我们这个main程序就没有那么容易被删除了。

cmake_install.cmake文件

这个安装模块可是和cmake_install.cmake息息相关

这个文件里面就存储了我们到底要怎么进行安装

install_manifest.txt文件

执行了安装之后，就会另外生成下面这个文件

这个就是我们已经安装的资源清单

2.6.测试打包模块

在 CMake 项目中，除了可以通过 install 命令将生成的目标文件（如可执行程序或动态库）安装到本地系统目录之外，还可以借助 CPack 工具将相关文件打包成压缩包的形式进行分发和共享，这种方式便于软件在不同环境之间的传递和部署。

若项目的 CMake 配置文件 CMakeLists.txt 中引入了 CPack 功能（通常通过 include(CPack) 实现），则在生成的构建系统文件（例如 Makefile）中也会自动包含一个名为 package 的伪目标。用户可通过执行诸如 make package 这样的命令触发打包流程，CPack 会自动根据安装规则收集所有应安装的文件，并生成指定格式的发布包。

这种机制不仅支持生成跨平台的标准压缩包格式（如 ZIP、TGZ 等），还可配置生成系统特定的安装包格式，如 Linux 下的 RPM 或 DEB 包，以及 Windows 上的 NSIS 安装包，极大提升了项目发布和部署的灵活性与便利性。

我们看看怎么使用啊

cpack
或者
make package

打包之前，我们先看看目录里面有什么

我们现在执行打包

打包之后，我们再看看当前目录有什么

我们重点关注helloWorld-0.1.1-Linux.tar.gz这么一个文件。

我们可以解压一下

可以看看它的结构

我们知道执行make install会生成一个文件install_manifest.txt，而cpace就是会读取和写入这个文件。

CPack 的执行过程

CPack 的执行过程是一个结构化的多步骤流程，旨在将构建产物可靠地打包为可分发的格式。其核心步骤可概括如下：

1. 首先，CPack 会在构建目录中创建一个专用的临时目录，通常命名为 _CPack_Packages。该目录作为模拟安装环境的沙盒，确保后续操作不会影响实际系统路径中的文件。
2. 随后，CPack 会主动执行由 CMake 自动生成的安装脚本 cmake_install.cmake。该脚本中包含了项目中通过 install() 命令定义的所有安装规则。此步骤的作用是将需要分发的目标文件（如可执行文件、库文件及资源文件）按照预设的安装逻辑部署到上述临时目录中，完全模拟一次本地安装的过程。
3. 接下来，CPack 会系统性地扫描并收集临时目录中所有已部署的文件，生成最终要打包的文件列表。这一机制确保了最终软件包的内容与项目配置的安装规则完全一致。
4. 最后，CPack 根据用户指定的或默认的包类型（如 ZIP、TGZ、RPM 或 DEB 等），对收集到的文件执行打包操作，生成压缩包或系统安装包。生成的软件包文件会被输出到项目的构建目录中，便于用户直接获取或进一步分发。

整个过程充分体现了 CPack 与 CMake 安装系统的紧密集成，确保软件包内容的管理既自动化又高度可靠。

临时目录的作用

我们可以看看这个临时目录的结构

我们仔细一看，嗯？跟我们解压出来的目录结构好像是一样的

---

我们用一个最简单的比喻来解释，保证你马上明白。

想象一下你要搬家。

• 你的所有物品 = 你编译好的程序文件（比如 main 和 testAdd 这两个文件）

• 新家的房间布局 = 电脑的目录结构（比如 /usr/local/bin 放程序，/usr/local/lib 放库）

• 打包好的纸箱 = CPack 最终生成的 .zip 或 .deb 压缩包

现在问题来了：你怎么确保打包时，东西都放对了箱子，并且到了新家能立刻找到？

最笨的方法：直接从旧房子的各个角落（你的项目文件夹）里乱抓一通，胡乱塞进纸箱。结果到了新家，你发现勺子可能在衣柜里，袜子可能在厨房里——全乱套了。

聪明的方法（也就是 CPack 的方法）：

1. 你先在客厅的空地上 (_CPack_Packages)，严格按照新家的布局，模拟摆放一次。

   • 比如，在地上画个圈，标上“厨房”，然后把所有厨房用品暂时放在这个圈里。

   • 再画个圈，标上“卧室”，把所有衣服暂时放在这里。

2. 检查一遍：看看“厨房”圈里是不是只有厨房用品，“卧室”圈里是不是只有衣服。确保每样东西都放在了正确的位置，没有漏掉任何东西。

3. 开始打包：现在你看一眼“厨房”圈，把里面的所有东西打包到一个箱子上，并在箱子上贴好标签“厨房”。再看一眼“卧室”圈，把所有东西打包到另一个箱子上，贴上“卧室”。

4. 最后，把这些打包好的纸箱（压缩包）运走。同时，把客厅地上画的圈（临时目录）擦掉，恢复原状。

所以，_CPack_Packages 就是这个“客厅的空地”！

它的作用就是：

1. 提供一个临时空间，让 CPack 能把你程序的所有文件，按照最终要安装的目录结构（如 bin, lib）先好好地、正确地摆放一次。

2. 检查一下有没有错误。

3. 从这个摆放好的、绝对正确的临时布局中，生成最终的压缩包。

这样做的巨大好处是：保证了压缩包里的结构，和安装到你电脑里的结构是一模一样的，绝对不会出错。

总结一句话：_CPack_Packages 就是 CPack 用来“预演”安装过程、确保打包结果万无一失的“临时排练场”。 打包一结束，这个排练场就被拆掉了。

make install和make package对于install_mainfest.txt的作用

执行 make install 时，系统会读取 install_manifest.txt 中列出的文件列表，并将其安装到指定的系统目标路径，默认情况下通常是 /usr/local。

执行 make package 或 cpack 时，系统同样会依据 install_manifest.txt 中的清单收集需要分发的文件，但并不会将其安装到系统路径中。相反，这些文件会被放置在一个专为打包创建的临时目录（通常命名为 _CPack_Packages）中，该目录模拟了目标系统的目录结构。

Cpack配置文件——CPackConfig.cmake

我给大家列举了一下CPackConfig.cmake的部分内容

还是有很多配置的，我们先不详细讲解。

同样我们的最简hello_world⼯程没实现cpack规则，其中就包括没有指定cpack⽣成器。在第三章 ⾥我们会详细介绍CPack的使⽤。

2.7 查看帮助

cmake --help