企业官网建设流程全解析

1. 先搞清楚"现代CMake"到底新在哪里

CMake 这个工具，说实话口碑挺分裂的。有人觉得它是 C/C++ 生态里唯一能跨平台管好构建的救星，也有人一看到那一堆CMakeLists.txt就想掀桌子。我身边不少做嵌入式和后端的朋友，做cmake编译的时候都遇到过同一个尴尬：项目能跑，但没人敢动构建脚本，改一行参数全崩。问题的根源其实不在 CMake 本身，而在于很多人写的是十年前那种"老式 CMake"——靠全局变量、include_directories、link_libraries到处撒命令的写法。

所谓"现代 CMake"，核心就一句话：一切以 target（目标）为中心。老写法是"我先设置一堆全局开关，然后大家各自编译"，现代写法是"每个库、每个可执行文件都是一个独立对象，它自己声明需要什么、对外暴露什么"。这个转变听起来抽象，但落到cmake使用教程的实操层面，就是你会用target_link_libraries代替link_libraries，会用target_include_directories代替include_directories，然后在后面加上PRIVATE、PUBLIC、INTERFACE三个关键字把依赖关系说清楚。

这篇内容我打算写得扎实一点。适合谁看？如果你正在从cmake下载安装起步，或者手里有个老项目想重构，又或者你在嵌入式方向琢磨"cmake 能不能代替 keil5"这类问题，那基本都能在这儿找到能直接抄的写法。我不会只给你一个模板了事，而是把每个选择背后的原因讲透——为什么要这么写、不这么写会踩什么坑、include($env{idf_path}/tools/cmake/project.cmake)这种看起来吓人的写法到底在干嘛。

我尽量按一个真实工程师的排查和重构思路来组织，从环境、机制、实战到排查一路走下来。中间会穿插我踩过的坑和一些常规文档不会写的小技巧。你不需要看到最后才动手，每一节都能独立落地。

2. 环境搭建：从下载安装到"命令找不到"的排查

环境这事看起来最简单，实际上cmake安装和版本问题劝退的人最多。我见过太多人卡在第一步，明明装好了却提示找不到命令，或者版本太老导致新语法不认。这一节把常见的几种情况一次说清楚。

2.1 三大平台安装方式的差异与选择

先说 Linux。这应该是最省心的，Ubuntu 上一条命令搞定：

sudo apt update sudo apt install cmake

但这里有个坑很多新手不知道：apt 源里的 CMake 版本往往偏老。你要写现代 CMake，特别是一些较新的target_*命令和生成器表达式，老版本会直接报语法错误。网上那些ubuntu cmake banben（版本）的搜索，多半就是被这个坑到的。装完先查一下版本：

cmake --version

如果版本低于你需要的，比如想用 3.20 以上的一些特性，apt 里只有 3.16，那就得考虑用 Kitware 官方仓库或者直接下预编译包。我个人更推荐新手直接用官方二进制包，解压后把bin目录加进 PATH，干净利落，还方便以后换版本。

macOS 用 Homebrew 最顺手，brew install cmake一句话的事。Windows 上就复杂点，官方安装包（.msi）和压缩包（.zip）两种，安装包里可以选"把 CMake 加入系统 PATH"，勾上这一步能省掉后面八成的麻烦。

提示：Windows 上还有一种省心方案，就是直接用 Visual Studio 自带的 CMake，或者用 Scoop、Chocolatey 这类包管理器。但如果你同时装了多个来源的 CMake，PATH 顺序会决定你用哪个版本，后面排查问题时要留意。

2.2 "无法将cmake项识别为cmdlet"到底怎么破

这个报错在 Windows PowerShell 里特别常见，完整的话是：cmake : 无法将"cmake"项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写...。看到这个先别慌，它跟 CMake 好不好用没关系，纯粹是系统不知道cmake.exe在哪。

排查顺序我建议这么走。第一步，确认到底装没装。去安装目录看看，默认一般落在C:\Program Files\CMake\bin下面。找不到就说明安装那步没选对路径，或者压根没装成功。第二步，看 PATH。Windows 上按 Win 键搜"环境变量"，打开"编辑系统环境变量"，进 PATH 里找有没有C:\Program Files\CMake\bin。没有就手动加上，然后一定要重开一个新的终端窗口，旧窗口不会自动刷新环境变量。

第三步，如果 PATH 加对了还是不行，用绝对路径直接调用试试：

& "C:\Program Files\CMake\bin\cmake.exe" --version

能出东西就说明程序没问题，是 PATH 的事。这里有个我踩过的坑：有些人装的是 CMake 的 GUI 版本（cmake-gui），只装了图形界面没装命令行，那cmake命令自然找不到。这种情况回去重装，安装类型选"Add CMake to the system PATH for all users"，问题基本就解决了。

还有一种情况，你用的是 Git Bash 或者 WSL，那 PATH 的规则又不一样。WSL 里默认是 Linux 环境，得在 Linux 侧重新装一遍，别指望 Windows 装的那份能直接用。

2.3 多版本共存与卸载的干净做法

真正做项目的时候，一台机器上好几个版本共存是常态。老项目依赖旧 CMake，新项目要新的，强行统一反而容易出事。我一般这么处理：把不同版本的 CMake 放在不同目录下，比如C:\tools\cmake-3.16和C:\tools\cmake-3.28，PATH 里只放你想默认用的那个。需要切换时，临时在命令行改 PATH，或者写个小脚本切。

Linux 上更干脆，官方二进制包解压即用，软链接到/usr/local/bin就行：

sudo ln -sf /opt/cmake-3.28/bin/cmake /usr/local/bin/cmake

换版本只需要重做这个软链接，不动系统包，干净。

卸载方面，Windows 上如果是 msi 装的，走控制面板卸载最稳妥，卸载完记得回去 PATH 里把残留的路径删掉。zip 版的手动删目录就行。Linux 上 apt 装的用sudo apt remove cmake，二进制包安装的直接删目录、删软链接。我倾向于能用二进制包就用二进制包，卸载意味着"删目录"，不留任何系统痕迹，这在多台机器批量部署时太香了。

注意：卸载前先确认没有项目正在引用某个特定版本的 CMake。我有一次手快把默认版本卸了，结果一个 CI 脚本挂了一整天，最后发现就是个版本问题。养成习惯，卸载前cmake --version记一下，必要时先钉住版本。

2.4 用一个最小工程验证环境是否真的可用

装完别急着上复杂项目，先跑个最小验证。建两个文件：

# CMakeLists.txt cmake_minimum_required(VERSION 3.16) project(hello CXX) add_executable(hello main.cpp)

// main.cpp #include <iostream> int main() { std::cout << "cmake ok" << std::endl; return 0; }

然后标准三步走：

cmake -S . -B build cmake --build build ./build/hello

我特意用-S . -B build这种写法，而不是进去build目录再cmake ..。这是现代 CMake 推荐的方式，语义清晰，-S指定源码目录，-B指定构建目录，一条命令搞定，还方便脚本化。能打印出cmake ok，说明环境彻底没问题了，可以往下走了。

3. target为核心的现代CMake核心机制

环境通了，接下来是理解现代 CMake 真正的"内功"。这一节的东西如果你能吃透，那么后面无论面对多大的项目，思路都不会乱。我把它拆成三块：可见性关键字、生成器表达式、以及目录属性和目标属性的区别。

3.1 PRIVATE、PUBLIC、INTERFACE 三个关键字的含义

这三个词是现代 CMake 的灵魂，理解它们就等于理解了依赖传播。打个比方：你设计一个库，它内部用到的依赖，到底是"只给自己用"，还是"我用了，用我的人也得用"，还是"我自己不用，但用我的人必须用"。这三种情况，分别对应 PRIVATE、PUBLIC、INTERFACE。

举个最直观的例子。假设你有个库mylib，它内部用了某个fmt库来格式化字符串，但 fmt 只出现在.cpp实现里，头文件对外不暴露 fmt 的任何类型。那么：

target_link_libraries(mylib PRIVATE fmt::fmt)

意思是：fmt 只是我 mylib 自己用的，谁链接我，不需要知道 fmt 的存在。反过来，如果你的头文件里直接#include <fmt/format.h>并且暴露了 fmt 的类型，那依赖就得往外传：

target_link_libraries(mylib PUBLIC fmt::fmt)

PUBLIC 等于"我自己用，也传给别人"。而 INTERFACE 是"我自己不用，但用我的人要用"，典型场景是纯头文件库（header-only），它没有编译单元，但会把依赖和要求传递下去。

我实测下来，很多老项目最大的毛病就是所有依赖都当成"全局"处理，导致链接顺序、重复链接、符号冲突一堆问题。用这三个关键字把边界卡死，这些问题一大半会自然消失。理解它的关键是记住：依赖是有方向的，从"谁用"流向"谁提供"。

提示：如果你不确定某个依赖该用哪个，问自己一句——"我的公开头文件里有没有用到这个依赖的类型/宏？"有用 PUBLIC，没用但实现需要 PRIVATE，完全没有编译单元只想传依赖用 INTERFACE。

3.2 生成器表达式：把条件判断推迟到构建时

生成器表达式（generator expression）是老 CMake 里几乎不存在的概念，也是现代 CMake 里最能体现"高级"的部分。它的核心思想是：有些信息在配置阶段（cmake 运行时）还没定，得等到构建阶段（真正编译时）才知道。比如 Debug 和 Release 用不同路径、不同平台用不同库名。

拿常见的写法举例：

target_include_directories(mylib PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> $<INSTALL_INTERFACE:include> )

这里$<BUILD_INTERFACE:...>表示"在构建这个库自身时用这个路径"，$<INSTALL_INTERFACE:...>表示"当这个库被安装后、别人引用它时用这个路径"。两种场景路径不一样，生成器表达式正好能表达。这是现代 CMake 里发布库的标准姿势，老写法是根本做不到这么干净的。

再比如按配置区分：

target_compile_definitions(mylib PRIVATE $<$<CONFIG:Debug>:DEBUG_BUILD> )

意思是只有 Debug 配置下才加DEBUG_BUILD这个宏。$<CONFIG:Debug>是个条件，外层$<...:...>是"满足条件就展开成冒号后面的内容"。

刚接触这玩意会觉得语法像天书，我的建议是先抄现成的模式，用多了自然就熟了。记住规律：$<关键字:参数>是读取某种信息，$<条件:值>是条件判断，可以嵌套，从内往外读。

3.3 目录属性 vs 目标属性：为什么后者才靠得住

这是理解现代 CMake 最容易被忽略、但影响最大的一点。老写法里include_directories、add_definitions操作的是目录属性，它会"传染"到该目录下所有子目录和后续定义的所有目标。结果就是依赖关系变得隐式、隐晦，你只看某个 target 的配置根本不知道它实际用了哪些头文件路径。

现代写法里，target_include_directories、target_compile_definitions这些操作的是目标属性，只作用于你指定的那个 target，而且能通过 PUBLIC/INTERFACE 精确控制传播。对比一下：

为什么后者更可靠？因为构建系统本质上应该是一张"依赖图"，每个节点声明自己的输入输出。目录属性相当于往一个全局袋子里丢东西，谁都能捞;目标属性相当于每个节点自带标签。项目一大，前者必然乱套，后者还能理清。这也解释了为什么现代 CMake 强调"不要污染目录属性"——一旦用了目录级命令，整个工程的可维护性就直线下降。

4. 实战：把老项目改造成现代CMake工程

理论讲完，来点硬货。这一节我拿一个典型的多模块 C++ 项目做例子，走一遍从目录设计到依赖引入的完整流程。你手里的项目无论大小，思路都通用。

4.1 目录结构怎么设计才合理

先说结构。现代 CMake 项目我推荐这样的布局：

project/ ├── CMakeLists.txt ├── cmake/ │ └── helpers.cmake ├── include/ │ └── mylib/ │ └── mylib.h ├── src/ │ ├── CMakeLists.txt │ ├── mylib.cpp │ └── main.cpp └── tests/ ── CMakeLists.txt

顶层CMakeLists.txt只负责工程定义和子目录接入，include/专门放对外暴露的头文件，src/放实现，tests/放测试。这个划分的好处是：include和src物理分离，库使用者只需要include路径，不会误把实现细节暴露出去。

有经验的人可能会问：那内部用的私有头文件放哪？我的做法是在src/下再建一个detail/或者internal/，通过PRIVATE方式加进 target，对外不可见。这种"公开/私有"头文件分离是大型项目的基本功，后面发布库的时候能省掉大量麻烦。

4.2 顶层 CMakeLists.txt 的标准写法

顶层文件我一般这么写：

cmake_minimum_required(VERSION 3.16) project(mylib VERSION 1.2.0 DESCRIPTION "一个示例库" LANGUAGES CXX) # 全局设置：C++ 标准、默认构建类型 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) if(NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE Release CACHE STRING "Build type" FORCE) endif() # 统一输出目录，方便找产物 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) add_subdirectory(src) enable_testing() add_subdirectory(tests)

几个细节解释一下。set(CMAKE_CXX_STANDARD 17)是全局设标准，比给每个 target 单独设省事。但如果你项目里混合了不同标准（比如老模块要 C++11），那就得改成 target 级别设置。

CMAKE_CXX_EXTENSIONS OFF是关掉编译器的 GNU 扩展，强制标准行为，做跨平台项目时尤其重要，不然在 GCC 上能编过、Clang 上就翻车。

默认构建类型的判断也值得说：不设的话，单配置生成器（Makefile、Ninja）默认是空，编译出来的东西没有任何优化，性能差好几倍你还以为是代码问题。这里强制默认 Release，需要 Debug 时显式-DCMAKE_BUILD_TYPE=Debug。

4.3 库目标和可执行目标的写法

src/CMakeLists.txt是关键，我把库和可执行文件都写在这：

# 定义库目标 add_library(mylib mylib.cpp ) add_library(mylib::mylib ALIAS mylib) target_include_directories(mylib PUBLIC $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include> $<INSTALL_INTERFACE:include> PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/detail ) target_compile_features(mylib PUBLIC cxx_std_17) # 定义可执行目标 add_executable(app main.cpp) target_link_libraries(app PRIVATE mylib::mylib)

注意add_library(mylib::mylib ALIAS mylib)这一行。这是给库起一个带命名空间的名字，之后所有引用都统一用mylib::mylib。这样做有两个好处：一是防止名字冲突，二是将来这个库换成 find_package 引入的外部库时，写法完全一样，使用者无感知。这是我强烈推荐的习惯，做多了项目的都知道命名空间带来的规范性有多重要。

target_compile_features(mylib PUBLIC cxx_std_17)也值得说。它比直接set(CMAKE_CXX_STANDARD)更精确——它声明的是"这个库要求使用 C++17 特性"，用它的 target 会自动继承这个要求。这是现代 CMake 的"按需声明"思想，比全局设置更精细。

4.4 引入第三方依赖的正确姿势

第三方库是现代 CMake 里最容易出问题的环节。主流两种方式：find_package和FetchContent。

find_package找系统里已装的库：

find_package(fmt REQUIRED) target_link_libraries(mylib PRIVATE fmt::fmt)

关键是REQUIRED，找不到直接报错退出，而不是默默继续导致后面一堆链接错误。很多人不写 REQUIRED，结果编译到一半才炸，排查成本翻倍。

FetchContent是配置阶段就把依赖下载进来：

include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG v1.14.0 ) FetchContent_MakeAvailable(googletest) target_link_libraries(tests PRIVATE GTest::gtest_main)

这两种方式怎么选？我的经验是：系统里稳定的依赖用find_package，构建快;需要固定版本、或者 CI 环境干净想一键拉齐的，用FetchContent。但FetchContent每次配置都可能触发网络请求，离线环境会卡住，所以我一般会加个开关或者设好本地缓存路径。

注意：FetchContent 的 GIT_TAG 一定要钉死到具体版本或 commit，别用main。我有次偷懒用了 main，结果上游改了个 API，第二天 CI 全线飘红，排查半天才发现是依赖自己动了。钉版本这件事，一次都别省。

5. 交叉编译与嵌入式场景：cmake 能不能顶替 keil5

这是个被问爆的问题：cmake 可以代替 keil5 吗？我的回答是：能，但要看你怎么用。CMake 本身只是构建系统的生成器，它不懂芯片、不烧录、不调试。它做的是把你的源码、编译参数、链接脚本组织好，交给交叉编译器（比如 arm-none-eabi-gcc）去干活。调试和烧录则要靠 OpenOCD、J-Link 这些工具。所以准确说，是"GCC + CMake + OpenOCD/J-Link"这一整套，替代了 keil5 的工作流。

5.1 工具链文件的写法

交叉编译的核心是工具链文件（toolchain file），它告诉 CMake 用哪个编译器、哪个系统根目录。我以一个 ARM Cortex-M 项目为例：

# arm-none-eabi.cmake set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_SYSTEM_PROCESSOR arm) set(TOOLCHAIN_PREFIX arm-none-eabi-) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}g++) set(CMAKE_ASM_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

CMAKE_SYSTEM_NAME Generic是裸机环境的标准写法，告诉 CMake 没有操作系统。CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY这行很关键，因为交叉编译器通常没法独立链接出一个可执行文件（缺启动文件和链接脚本），设置成静态库可以让 CMake 的编译器探测通过，不然配置阶段就会失败。这个坑我见太多人栽了，配置时报"compiler not able to compile a simple test program"，八成就是这个原因。

用的时候这样调用：

cmake -S . -B build-arm -DCMAKE_TOOLCHAIN_FILE=cmake/arm-none-eabi.cmake cmake --build build-arm

链接脚本通过 target 属性传进去：

target_link_options(firmware PRIVATE -T${CMAKE_SOURCE_DIR}/linker/stm32.ld -Wl,-Map=${CMAKE_BINARY_DIR}/firmware.map --specs=nano.specs )

--specs=nano.specs是给裸机用的精简 C 库，能省不少 Flash 空间，这些小参数在 keil 里是默认配好的，换成 GCC 就得自己加。

5.2 调试与烧录：J-Link 和 OpenOCD 的接入

既然换掉了 keil5，调试这环得自己搭。用 J-Link 的话，可以通过 J-Link 的命令行工具或者 GDB Server。常见的做法是启动 GDB Server，然后用arm-none-eabi-gdb连上去：

JLinkGDBServer -device STM32F407VG -if SWD -speed 4000

另一个终端：

arm-none-eabi-gdb build-arm/firmware.elf (gdb) target remote localhost:2331 (gdb) load (gdb) monitor reset

如果你在搜cmake jlink相关的写法，通常就是想把上面这些集成进 CMake。我的建议是别把烧录硬塞进 CMake 的构建流程里，那会让构建变慢、变脆。正确做法是单独写一个 target 或者脚本，比如：

add_custom_target(flash COMMAND JLinkExe -device STM32F407VG -if SWD -speed 4000 -autoconnect 1 -CommanderScript ${CMAKE_SOURCE_DIR}/scripts/flash.jlink DEPENDS firmware COMMENT "烧录固件到目标板" )

这样cmake --build build-arm --target flash就能一键烧录，但它是独立目标，不影响正常构建。OpenOCD 的方式类似，配好 cfg 文件后通过add_custom_target包一层即可。

对比一下 keil 和这套开源方案，我的实际体会是：

一句话总结：个人快速验证、追求开箱即用，keil 更省事;团队协作、需要 CI、要跨平台，现代 CMake 方案更值得投入。这不是非此即彼，很多团队是"开发用 keil 验证，CI 用 CMake 构建"，各取所长。

6. 常见问题与排查技巧实录

这一节是我这些年踩坑攒下来的经验，很多是文档里不会写、但实际天天遇到的问题。我整理成速查表加几条独家心得。

6.1 高频报错速查表

先上表格，照着查能省一半排查时间。

最后一行的include($env{idf_path}/tools/cmake/project.cmake)是很多人搜的写法。它来自某些嵌入式框架的工程模板，本质是"读取环境变量 idf_path，然后 include 那个路径下的工程脚本"。如果你照抄却报错，九成是环境变量idf_path没设置，或者路径拼接不对。排查方法：先echo $env{idf_path}（Windows）或echo $IDF_PATH（Linux）确认变量有值，再确认路径下真有那个文件。变量的写法跟平台有关，Linux 下include($ENV{IDF_PATH}/...)，Windows PowerShell 里环境变量读取也可能有差异，别照搬。

注意：CMake 里读取环境变量用$ENV{NAME}，读取普通变量用${NAME}，两者别搞混。include($env{idf_path}...)这种小写写法在很多框架里能用是因为它们有自己的解析，标准 CMake 里环境变量要用大写$ENV{}。抄的时候先搞清楚来源。

6.2 缓存问题：改了半天没反应的真凶

CMake 把配置结果缓存在构建目录里，这是它区别于纯 Makefile 的一个特点。好处是配置快，坏处是——你改了CMakeLists.txt但结果没变，或者更糟，报一些莫名其妙的错。这种情况九成是缓存导致的。

我的处理原则很简单：遇到说不清的构建问题，先删 build 目录重来一次。

rm -rf build cmake -S . -B build

这一步能解决我大概 60% 的诡异问题。如果不想全删，也可以只删缓存文件CMakeCache.txt，但有时候生成的中间产物也会残留，全删最省心。CI 里我更激进，每次都是干净构建目录，虽然慢点，但避免了一切缓存污染。

有一类缓存坑特别隐蔽：你之前配了-DCMAKE_BUILD_TYPE=Debug，后来想改 Release，但没删缓存直接重配，结果 CMake 没更新。正确的做法是重新配置并指定新值，或者干脆删缓存。改编译选项、改工具链、改依赖路径这类操作，我都会连带清一次缓存。

6.3 依赖可见性引发的链接错误排查思路

链接错误是最让人头大的，因为编译器不告诉你"是谁需要这个符号"。遇到 undefined reference，我按这个顺序排查：

第一步，看这个符号属于哪个库。比如fmt::format明显来自 fmt。第二步，看哪个 target 用了它，可见性设置是否合理。第三步，如果库只在实现里用（PRIVATE），但被别的 target 间接需要，那就得改成 PUBLIC 往外传。第四步，确认链接顺序——现代 CMake 通过 target 关系自动排序，但如果用了老式link_libraries，顺序就得手动管。

我个人的经验是：老老实实用 target_link_libraries + 正确的可见性，几乎不会遇到链接顺序问题。链接顺序这个东西在现代 CMake 里基本被自动处理了，你一旦开始手动-l调顺序，就说明哪里架构出问题了，回去看看依赖声明对不对。

6.4 几个能直接抄的实用小技巧

最后分享几个我常用的小技巧，都是能立刻用上的。

第一，用cmake --build build --target help看所有可用目标。这比去翻 CMakeLists 快多了，尤其接手别人项目时。第二，用-DCMAKE_EXPORT_COMPILE_COMMANDS=ON生成compile_commands.json，配合 clangd、VSCode，代码跳转和补全瞬间起飞：

cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

这个文件是 C++ 生态里做 IDE 集成的通用格式，装完不用再担心头文件路径识别不了。

第三，用CMAKE_VERBOSE_MAKEFILE或者cmake --build build --verbose看真实的编译命令。当你不确定某个宏、某个 include 路径有没有生效时，看编译命令行是最直接的验证方式，比猜强一万倍。

第四，写库的时候尽早考虑install和export规则。很多人做完功能就不管了，等到要把库发布给同事用时才发现没法find_package。现代 CMake 里install(TARGETS ... EXPORT ...)加上install(EXPORT ...)这套组合拳，配合生成器表达式的$<INSTALL_INTERFACE:...>，一次配好，终身受益。

我在实际带团队时最大的体会是：现代 CMake 的价值不在语法多花哨，而在于它逼着你把工程的依赖关系想清楚。老写法可以糊弄，现代写法糊弄不了——你写不出正确的 PUBLIC/PRIVATE，说明你对模块边界的理解还没到位。所以重构 CMake 的过程，往往也是重新梳理项目架构的过程。这个附加价值，比省下的那点打字时间值钱多了。