很多写C++的朋友第一次接触CMake，都是因为项目从单个cpp文件变成了十几个文件，又或者是从GitHub上拉了一个项目下来，发现根本没有Visual Studio的.sln，也没有Makefile，只有一堆CMakeLists.txt。网上教程一搜一大把，但大多要么只讲“照着敲”的步骤，要么直接扔出几百行配置让你复制，看完还是不清楚每一行在干什么。这篇文章我想换个思路，直接从“为什么会需要CMake”这个问题切入，把使用CMake编译项目的完整逻辑链讲明白。读完之后你不仅能跑通第一个CMake项目，还能自己判断项目该怎么组织、依赖该怎么引、报错该怎么查。这系列是第一期，先把编译和构建这条主线拿下。
1. CMake到底解决了什么：先想清楚为什么需要它
很多新手一上来就背CMake命令，结果遇到一个不熟悉的项目结构仍然不知道从哪下手。我的建议是先把问题还原出来，你才能真正理解CMake每一项设计背后的理由。
1.1 手写g++命令编译项目，痛点在哪里
假设你正在写一个很小的C++程序，只有三个文件：main.cpp、utils.cpp、utils.h。传统的编译方式是在终端里执行一行g++命令：
g++ -std=c++17 -Wall -O2 main.cpp utils.cpp -o app文件少的时候，这行命令勉强能接受。但项目一旦开始涨，问题立刻就来了：
- 文件从三个变成三十个，命令行会变得非常长，而且每次都要重复敲。
- 想切换Debug和Release，需要手动换优化参数和宏定义，非常容易出错。
- 依赖了第三方库之后，还要手写头文件路径
-I和库文件路径-L以及库名-l，记忆负担成倍增加。 - 你只在某个平台上的某个编译器上验证过，换到Windows用MSVC，或者换到macOS用Clang，命令又不一样了。
更麻烦的还有增量编译。三十个文件全量编译一次可能只要几十秒，但如果你每次都把全部文件重新编一遍，到了几百个文件的规模，一次全量编译可能就是十几分钟，改一行代码就要等这么久，完全没法干活。手写命令行基本做不到“只重新编译修改过的文件”这件事，你得自己用文件时间戳去判断，这不现实。
1.2 CMake不是“Make的替代品”，而是“构建系统的生成器”
这里有一个核心误区要先纠正：很多人以为CMake是替代Make的工具，其实不对。CMake本身并不负责编译，它做的事情是——根据你写的CMakeLists.txt，生成一份当前平台、当前编译器能直接使用的构建文件，然后再让底层的构建工具去真正干活。
我画个简单的链条来帮助理解：
CMakeLists.txt ↓ 配置阶段（Configure） CMake 根据平台、编译器、选项生成 ↓ 构建文件（Makefile / Visual Studio 工程 / Ninja文件 / Xcode工程） ↓ 构建阶段（Build） 调用编译器（g++ / cl.exe / clang++）完成编译链接 ↓ 最终可执行文件或库这就像你在写一份“菜单”，CMake负责把菜单翻译成中外厨师都能看懂的“分步烹饪卡”。你不需要关心用的是燃气灶还是电磁炉，CMake根据厨房（平台）自动决定。这份菜单还可以带可选条件，比如“如果厨房里有烤箱，就做烤鸡，否则改成煎鸡”——这就是CMake里的条件判断和选项。
理解了这层之后，你就不会再问“CMake和g++有什么区别”这种问题了，因为两者根本不在同一个层级：g++是编译器，CMake是构建系统生成器。编译工作最终还是由g++完成的，CMake只是把“用什么参数、按什么顺序、编译哪些文件”这些决策自动生成出来。
1.3 与Makefile、IDE工程文件的本质区别
可能有人会想：那直接用Makefile不就行了？或者直接在Visual Studio里建工程不就行了？确实可以，但各有各的限制。
Makefile的问题在于跨平台。Linux上用GNU Make，Windows上就算装了MinGW，很多写法也不通用。而且Makefile的语法比较“原始”，定义变量、处理依赖、支持不同编译器的分支逻辑，写起来远不如CMake可读。你想在Makefile里表达“这个库只在你开了某个选项时才链接”，脚本味道会非常重。
IDE工程文件（比如Visual Studio的.sln/.vcxproj）则是另一个极端：在Windows上体验很好，但换到Linux后端开发环境就完全无效。更麻烦的是，.vcxproj本质上是XML，手动改起来非常痛苦，也不适合做代码评审。团队协作的时候，每个人用不同IDE，工程文件怎么同步？这几乎是一场灾难。
CMake在这两者之间找到了一个平衡点：它用一套可读性较高的声明式语法描述构建逻辑，不绑定任何平台和IDE，然后通过“生成器”这个概念输出不同平台需要的格式。所以同一个CMakeLists.txt在Linux上生成Makefile，在Windows上可以生成Visual Studio工程，在macOS上可以生成Xcode工程，甚至可以用Ninja这种更快的构建系统来替代Make。一套代码，到处构建，这才是CMake最核心的价值。
2. 第一个CMake项目：CMakeLists.txt的完整解剖
光讲理论没有用，这一节直接动手。我会从环境准备开始，带你写出一个能编译通过的最小CMake项目，同时把每一个关键元素解释清楚。
2.1 环境准备：现在应该装哪个版本的CMake
CMake的安装在不同平台上有不同方式，我只列最常见的几种：
| 平台 | 安装方式 | 说明 |
|---|---|---|
| Ubuntu/Debian | sudo apt install cmake | 版本可能偏旧，但够用 |
| Windows | 官网下载安装包，安装时勾选“Add CMake to system PATH” | 这一步最容易漏，后面会讲 |
| macOS | brew install cmake | Homebrew安装 |
| 通用 | pip安装：pip install cmake | 适合没有管理员权限的场景 |
版本选择上，我的建议是CMake 3.16以上比较稳妥。很多第三方库的最低CMake版本要求就是3.16或者3.18，太旧的版本在引入依赖时容易出问题。CMake 3.10以前的版本连target_link_libraries的某些用法都有坑，不推荐新项目使用。
安装完之后，在终端验证一下：
cmake --version能打印出版本号就行。Windows环境如果提示“cmake不是内部或外部命令”，或者PowerShell提示“无法将‘cmake’项识别为cmdlet”，大概率是安装时没勾选加入PATH，要么重装勾选，要么手动把CMake的bin目录加到系统环境变量里。
2.2 最小CMakeLists.txt：逐行解释
先创建一个最简单的项目目录：
demo/ ├── CMakeLists.txt └── main.cppmain.cpp就写一个标准Hello World：
#include <iostream> int main() { std::cout << "Hello CMake!" << std::endl; return 0; }CMakeLists.txt长这样：
cmake_minimum_required(VERSION 3.16) project(HelloDemo LANGUAGES CXX) add_executable(hello_demo main.cpp)就这三行，已经能编译出一个可执行文件了。我来逐行解释为什么是这三行，以及它们各自的作用。
第一行cmake_minimum_required(VERSION 3.16)是声明CMake的最低版本。这行很关键，因为CMake的语法在不同版本间有细微变化，如果项目里用了高版本才有的特性，而使用者电脑上是最老版本，就会报错。反过来，声明了一个较低版本，CMake也会以兼容模式运行，行为更可预期。
第二行project(HelloDemo LANGUAGES CXX)是声明项目名称和语言。项目名称会被CMake用作变量引用，比如PROJECT_NAME；LANGUAGES CXX表示这个项目只用C++。不写LANGUAGES时，CMake默认会检测C和CXX两种语言，会导致某些场景下多引入C编译器依赖，所以显式声明更干净。
第三行add_executable(hello_demo main.cpp)是定义一个可执行文件目标，目标名是hello_demo，编译时源文件是main.cpp。这里有个很重要的概念：target（目标）。CMake里的一切核心操作都是围绕target展开的，后面引入库、配置头文件路径、设置编译选项，全都挂在target上，而不是全局生效。这一点先记住，第三部分的进阶改造全靠它。
2.3 为什么一定要在build目录里运行cmake
在刚才的demo目录下，如果你直接这么做：
cd demo cmake .也能生成构建文件，但CMake会把一大堆中间文件（CMakeCache.txt、CMakeFiles/目录、cmake_install.cmake等）散落在源码目录里。这就是所谓的源码内构建（in-source build）。
我强烈建议不要这么做，因为这会把你的源码目录弄得非常脏。更麻烦的是，如果你后来想在同一个源码目录下同时做Debug和Release两种配置，两者会产生冲突，编译产物互相覆盖，想清理都不知道从何下手。
正确的做法是创建一个独立的构建目录，比如在demo下建一个build：
cd demo mkdir build cd build cmake ..这样一份源码，可以对应多个构建目录：
demo/ ├── CMakeLists.txt ├── main.cpp ├── build-debug/ # Debug版本构建目录 └── build-release/ # Release版本构建目录每个构建目录里都可以配置不同的编译参数，互不干扰。这种模式在CMake术语里叫源码外构建（out-of-source build），这也是我后面所有示例默认采用的方式。
还有个细节顺便说一下：在build目录里运行cmake时，传给它的参数是源码根目录的路径，也就是包含顶层CMakeLists.txt的那个目录。我用..是因为build在demo内部。
2.4 cmake与cmake --build：两个命令的分工
配置完成之后，build目录里已经生成了Makefile（Linux/macOS默认生成器）或者Visual Studio工程（Windows默认生成器）。接下来执行编译：
cmake --build . --config Release这条命令是跨平台的“通用构建指令”。它会自动调用当前目录对应的底层构建工具（Make也好、Ninja也好、MSBuild也好）。所以你在Linux上用它，Windows上也能用它，不需要学习不同平台各自的构建命令。--config Release在多配置生成器（比如Visual Studio）下才有意义，单配置生成器（比如Makefile）一般用-DCMAKE_BUILD_TYPE=Release来指定编译类型。
很多初学者会直接把cmake --build .理解成“编译命令”，这是对的，但你要知道这背后实际发生的是CMake去调用了Make或MSBuild。还有一种做法是跑make命令直接编译，但在Windows的Visual Studio生成器下没有Makefile，就只能用cmake --build .。所以为了跨平台一致，我统一推荐用cmake --build .。
编译成功之后，build目录里会出现一个名为hello_demo的可执行文件（Windows下是hello_demo.exe），运行即可看到输出。
3. 项目变大以后：多目录组织与target化改造
单文件的示例只适合入门，真正写项目必然要把代码按模块拆到多个目录里。这一节我会用一个经典的结构演示：把一个程序拆成src/和include/两个目录，同时把核心逻辑做成一个静态库，让main.cpp直接链接这个库。
3.1 拆目录带来的三个新问题
假设项目变成了这样：
demo2/ ├── CMakeLists.txt ├── src/ │ ├── main.cpp │ ├── math_utils.cpp │ └── math_utils.h └── include/ └── demo2/ └── logger.h此时你会遇到三个新问题：
add_executable的源文件列表里要写路径，比如add_executable(hello_demo src/main.cpp src/math_utils.cpp)，文件一多列表就很长。- 编译器需要知道去哪里找头文件。math_utils.h在src目录下，logger.h在include/demo2目录下，不告诉编译器头文件搜索路径，编译会直接报
fatal error: logger.h: No such file or directory。 - 如果要把一部分代码编成库而不是全部打到一个可执行文件里，需要明确哪些文件属于库、哪些属于可执行程序。
这三个问题的解决方案分别对应CMake的三个核心命令：add_library、target_include_directories和target_link_libraries。
3.2 用add_library把核心代码变成库
我们把math_utils做成一个静态库，这样main.cpp只依赖一个库目标，而不是直接编译math_utils.cpp。CMakeLists.txt写成这样：
cmake_minimum_required(VERSION 3.16) project(Demo2 LANGUAGES CXX) add_library(math_utils STATIC src/math_utils.cpp ) add_executable(demo2_app src/main.cpp ) target_include_directories(math_utils PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/src ${CMAKE_CURRENT_SOURCE_DIR}/include ) target_link_libraries(demo2_app PRIVATE math_utils )add_library(math_utils STATIC src/math_utils.cpp)创建了一个静态库目标。STATIC表示静态库，在Linux下会生成libmath_utils.a，在Windows下会生成math_utils.lib。如果想生成动态库，把STATIC换成SHARED即可。
target_include_directories里的PUBLIC和PRIVATE是关键。PUBLIC表示这个头文件目录不仅自己编译时要用，链接它的其他目标也要用；PRIVATE表示只有自己内部使用。在这个例子里，math_utils.cpp引用了src/math_utils.h，所以include目录对它自己是需要的；demo2_app链接了math_utils，它也需要能找到math_utils.h，所以这里用PUBLIC。
3.3 target_include_directories与include_directories：为什么新版推荐前者
老版本的CMake教程里经常出现include_directories()，它是一刀切的全局设置，作用范围是“从此以后所有目标都加上这个头文件搜索路径”。这种写法在小项目里很省事，但问题也很明显：
- 所有目标被强制塞入全部头文件路径，命名空间被污染。
- 无法表达“这个库需要这个头文件路径，其他库不需要”的依赖关系。
- 一旦目标之间有同名头文件，搜索优先级会让你怀疑人生。
而target_include_directories是把头文件路径挂在具体target上，并且通过PUBLIC/PRIVATE/INTERFACE三个关键字控制传播范围。这种现代写法虽然繁琐一点，但依赖关系非常清晰。CMake官方文档也明确推荐用target化的命令。
同理，target_link_libraries(demo2_app PRIVATE math_utils)表示demo2_app链接math_utils库，PRIVATE表示这种链接关系只对demo2_app自身有效，不会继续传播给其他链接demo2_app的目标。这里用PRIVATE是因为main.cpp不需要把自己链接的库再传给下游。
3.4 完整示例：编译与验证
把上面三个文件创建好之后，按老规矩：
mkdir build && cd build cmake .. cmake --build .CMake会自动完成以下工作：
- 编译math_utils.cpp，生成静态库libmath_utils.a。
- 编译main.cpp，生成目标文件main.cpp.o。
- 链接阶段，把main.cpp.o和libmath_utils.a一起链接成demo2_app可执行文件。
如果你想确认编译细节，可以在构建时打开verbose模式：
cmake --build . --verbose在Makefile生成器下，这会打印出完整的g++命令行。我强烈建议你至少看一次，它会让你把“CMake生成构建文件”和“编译器真正执行的命令”两件事对应起来，很多困惑都会迎刃而解。
4. 引入第三方依赖：find_package的正确打开方式
真实项目不太可能完全没有第三方依赖。这一节我会说清楚find_package的基本原理和常见用法。内容偏进阶，但这是绕不过去的坎，早学会早省心。
4.1 为什么不能只靠“手动添加头文件路径”
最容易想到的方式是找到第三方库的头文件和库文件，然后手动用target_include_directories和target_link_libraries加进去。比如：
target_include_directories(app PRIVATE /usr/local/include/opencv4) target_link_libraries(app PRIVATE /usr/local/lib/libopencv_core.so)对于服务器上固定的项目，这样确实能跑通。但问题在于：
- 你写死的路径在其他机器上不存在，别人拉下来之后要手动改。
- 不同发行版、不同系统里，第三方库的安装位置差异很大，手写路径等于自断跨平台。
- 第三方库本身也可能依赖其他库，比如OpenCV依赖一堆图像编解码库，手写一个
-lopencv_core并不表示依赖关系全解决了。
find_package机制就是来解决这个问题的：它在系统里按照约定好的规则搜索已安装的库，把找到的头文件路径、库文件路径、依赖关系整理好，让你在CMakeLists.txt里用变量或imported目标直接引用。
4.2 find_package的模块模式与配置模式
find_package有两种工作模式，理解它们的区别，排错时会省很多力气。
模块模式（Module Mode）：CMake自带的FindXXX.cmake模块，或者你自己项目里的FindXXX.cmake，定义了一套搜索逻辑。比如find_package(Threads)会去查找线程库，并生成Threads::Threads这个目标。
配置模式（Config Mode）：库本身安装时自带了一个XXXConfig.cmake文件（通常在lib/cmake/XXX/目录下），里面直接写好了库目标的定义。比如OpenCV安装后会生成OpenCVConfig.cmake，find_package(OpenCV REQUIRED)就是读取这个文件。
判断某个库支持哪种模式，一个通用办法是看它装完之后有没有生成*-config.cmake或*Config.cmake文件。现代库基本都支持配置模式，这首先是因为配置模式对使用者最友好，其次CMake官方也在推动这一方向。
4.3 一个实用的查找流程
这里以连接线程库为例。
cmake_minimum_required(VERSION 3.16) project(ThreadDemo LANGUAGES CXX) find_package(Threads REQUIRED) add_executable(thread_demo main.cpp) target_link_libraries(thread_demo PRIVATE Threads::Threads )这个Threads::Threads就是CMake提供的一个imported目标。你不需要关心链接参数到底是-lpthread还是别的，CMake和Threads模块会替你做平台适配。在较新的glibc版本里，pthread函数已经合入libc，但老系统上需要显式链接，这个差异由find_package(Threads)帮你抹平。
再比如OpenCV，典型的用法是这样：
find_package(OpenCV REQUIRED COMPONENTS core imgproc)这一行要求找到OpenCV，并且至少包含core和imgproc两个组件。如果找不到，会直接报错并终止配置。找到之后，CMake会提供一个OpenCV::core这样的目标，或者一组OpenCV_INCLUDE_DIRS和OpenCV_LIBS变量。现代写法我更推荐直接用目标链接：
target_link_libraries(app PRIVATE opencv_core opencv_imgproc)不过不同版本OpenCV提供的目标名称不完全一致，实际项目里经常还要配合message(STATUS "OpenCV include: ${OpenCV_INCLUDE_DIRS}")打印出来确认一下。遇到find_package找不到库，先执行cmake时加-DCMAKE_PREFIX_PATH=/path/to/library/prefix，指定库的安装前缀，多半能解决。
5. 排错实录：初学者最容易栽的四个坑
这部分我希望你当成“医院急诊手册”来用。遇到什么症状，直接对查，能省下大量网上搜索的时间。
5.1 cmake命令找不到：环境变量与安装问题
高频问题，尤其Windows上常见。症状是终端或者VS Code的集成终端里执行cmake --version，提示：
- Windows cmd:
'cmake' 不是内部或外部命令，也不是可运行的程序或批处理文件。 - PowerShell:
cmake : 无法将“cmake”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。
原因基本只有两种：要么没装CMake，要么装了但没加入PATH。解决方法是重装安装包，在安装界面选“Add CMake to the system PATH for all users”，或者手动把CMake安装目录下的bin路径加入系统环境变量。
Linux上的情况一般少见，但如果用的是从源码编译的CMake，要留意是不是需要手动加PATH。macOS上如果直接下载了dmg版，有时也需要手动把/Applications/CMake.app/Contents/bin加进PATH。
5.2 改了CMakeLists.txt却不生效：缓存问题
很多新手会碰到的怪事：明明改了CMakeLists.txt里的某个配置，重新执行cmake --build .，但行为完全没变。这是因为CMake在首次配置时会生成一个CMakeCache.txt，把检测结果和用户配置都缓存了下来。如果新设置和缓存里的旧值发生冲突，CMake默认不会覆盖。
比如你改了set(CMAKE_BUILD_TYPE Release)，但CMakeCache.txt里已经记录了CMAKE_BUILD_TYPE=Debug，重新配置时会以缓存为准。
解决办法是在build目录里手动删掉CMakeCache.txt再重新执行cmake，或者指定一个新的build目录从零开始。需要注意的是，删除CMakeCache.txt之后，所有之前配置的选项（比如-D参数）都会丢失，需要重新传入。这也是我推荐你常用cmake -LAH .查看完整缓存列表的原因，它能帮你定位到底是哪个变量被缓存住了。
日常操作习惯是：改了CMakeLists.txt，正常重新构建就生效；只有遇到“改了不生效”的诡异情况，才需要动CMakeCache.txt。
5.3 undefined reference：链接顺序与target关联
编译阶段顺利，链接阶段报出一大堆undefined reference to 'xxx'。初学者看到这种错误第一反应是“代码有问题”，其实常常是链接时的库顺序或没有正确关联target导致的。
以g++直接举例，你大概知道链接库时要写在这个顺序：源文件在前，库在后。如果写反了，比如g++ -lmytool main.cpp，在某些编译器配置下可能会链接失败，因为链接器在处理-lmytool时还没有遇到需要它符号的目标文件，之后处理main.cpp时再遇到未定义符号，已经来不及回头从libmytool里取了。
在CMake里，这个问题通常不需要你手动管，但前提是你要用target_link_libraries明确关联库target。如果你只是手动通过target_link_libraries(app PRIVATE /path/to/libmytool.a)指定了库文件路径，而没有把它的依赖关系也挂上去，一旦这个库本身又依赖了别的库，undefined reference便会卷土重来。
排查思路我给个流程：
- 先看是编译错误还是链接错误。编译错误一定会有具体的源文件路径和行号，链接错误出现的是未定义符号。
- 如果是链接错误，先确认相关库是否确实
target_link_libraries到了目标上。 - 如果库本身有依赖，用
pkg-config或者find_package引入，而不是手动写路径。 - 在Makefile生成器下，用
cmake --build . --verbose看实际链接命令行，确认库顺序。
5.4 中文路径与生成器兼容性
最后一个坑和代码无关，但实实在在影响体验：项目路径别有中文和空格。
CMake本身对路径的处理能力在不断完善，但底层的编译器（尤其是Windows的MSVC）对中文路径的支持并不算好。遇到编译时出现奇怪的字符集报错，或者在文件读取时出现乱码文件名，优先检查项目路径是否包含中文。
VS Code配置C/C++环境时也经常遇到这个问题，.vscode里的路径配置如果有中文目录，调试器可能找不到符号文件。我的经验是项目一律用纯英文路径，这是成本最低的避坑方式。
另外，visualcpp编译器还有一个知名坑位：用Python的pip安装某些需要编译的C++扩展时，会提示error: Microsoft Visual C++ 14.0 or greater is required，这和你用CMake编译项目是两回事，但本质都要安装对应的Visual Studio Build Tools。如果之后要编译这类项目，装一下VS Build Tools就好，只是注意这里和CMake的依赖关系是独立的。
6. 从入门到进阶的一点路径建议
前面五节已经覆盖了一个CMake项目的完整生命周期：最小配置、多目录组织、库目标链接、依赖查找、常见排错。这一节我想从学习路径上说一点个人看法。
6.1 下一步可以学什么
如果你已经能独立用CMake配置一个多目录的C++项目，可以考虑以下几个方向：
- 用
set(CMAKE_CXX_STANDARD 17)管理C++标准版本，而不是靠编译命令一个个传。 - 用
add_definitions或target_compile_definitions管理预处理器宏，比如-DDEBUG这类。 - 用
option()定义开关，比如option(BUILD_TESTING "Build tests" ON)，把测试模块做成可选编译单元。 - 用
install()和export()把自己的库安装到系统目录，或者生成XXXConfig.cmake供其他项目调用。 - 用
FetchContent在配置阶段直接拉取第三方源码并构建，省去手动安装依赖的步骤。 - 把
cmake --build build --target install这一套完整跑通，理解库的安装与发布流程。
对复杂的项目，还可以了解pkg-config模块的概念，find_package(PkgConfig REQUIRED)配合pkg_check_modules在查找系统库时非常有用。
6.2 几条反直觉的经验
我自己的体会是，CMake的学习曲线不陡，但它有几个“反直觉”的点需要适应。
一是“配置”和“构建”两阶段分离。很多报错看起来是编译错误，实际是配置阶段就出了问题。遇到报错先看它出现在哪个阶段，别一头扎进源码里找bug。
二是CMake的变量作用域更像C++里的静态全局变量，而不是脚本语言的全局变量。函数（function）和宏（macro）里修改变量，作用范围不一样，写复杂函数时容易踩坑。
三是CMake版本敏感。一个在3.22上正常工作的项目，放到3.10上可能直接报语法错误。所以每次写CMakeLists.txt，我习惯在顶部用cmake_minimum_required标明最低版本，并且尽量只用兼容性好的写法，这样项目到别人手里不至于立刻爆炸。
四是多读CMake官方文档的target相关命令。坦白说，target_include_directories、target_link_libraries、target_compile_definitions这三个命令的PUBLIC/PRIVATE/INTERFACE语义是CMake现代写法的核心，吃透它们，比你背一百个命令都有用。
聊到这里，CMake编译项目的主线已经打通了。你可以从最简单的“三行CMakeLists编译一个Hello World”开始，一步步拆、一步步试，遇到报错就按第五节的思路去定位。下一期我准备聊聊CMake里的变量、函数、自定义命令，以及更复杂的项目组织方式，比如怎么把大型工程拆成若干子模块、怎么管理编译选项矩阵。感兴趣的话可以先动手把这一期里所有示例自己敲一遍，尤其是多目录和find_package的部分，动手跑过一遍和只看不练的差距比想象中大得多。
