引言：从”大锅饭”到”责任制”
在前面的章节中，我们已经学会了如何让CMake这位”施工队长”读懂建筑蓝图（Target），管理建筑材料（源文件），以及下达精细的工艺指令（编译与链接控制）。但如果你翻阅一些较老的CMake教程，或者接手公司的祖传项目，可能会看到另一种截然不同的写法：它们不使用target_include_directories，而是直接写include_directories；不用target_link_libraries，而是写link_libraries。
这种写法就像是在工地上用大喇叭广播：”所有人！一律使用三号水泥！所有人！都把头转向东边的仓库取料！”——不管你是一号楼的钢筋工，还是二号楼的电工，都得听这套指令。这在人少的工地或许管用，但当项目庞大、分工复杂时，必然造成混乱：电工拿错了水泥，钢筋工跑错了仓库，最终整个工地鸡飞狗跳。
从CMake 3.x开始，社区迎来了一场静默的革命。这场革命的核心只有一个：把”目录级”的全局指令，转变为”目标级”的精准属性。这就是现代CMake（Modern CMake）的灵魂，也是你从这节课开始，正式从”能用”迈向”精通”的分水岭。
要点1：从目录级变量到目标级属性的转变
旧时代的”目录思维”
在CMake 2.x时代，设计者把构建系统想象成一份按目录下发的行政命令。你在CMakeLists.txt顶层写下这样的代码：
# 老派CMake 2.x 风格（强烈不推荐）
include_directories(${CMAKE_SOURCE_DIR}/include)
add_definitions(-DENABLE_LOG)
link_libraries(math pthread)
add_executable(app main.cpp)
add_executable(tools helper.cpp)这段代码的问题在于：include_directories、add_definitions和link_libraries并不是在告诉CMake”如何构建app“，而是在说”在这个目录以及子目录下，所有后续诞生的目标都必须遵守这些规则”。
就像公司发了一份全部门适用的通知，只要你坐在这个办公室，就必须遵守。如果tools其实根本不需要math库，甚至因为链接了它导致体积膨胀或符号冲突，你也无可奈何。
现代CMake的”目标思维”
现代CMake提出了一个看似朴素、实则深刻的理念：一切构建信息都应该附着在目标（Target）上。没有目标，就没有构建。如果某个配置不属于任何具体目标，那它应该被包装成一个INTERFACE库（我们稍后会讲到）。
同样的需求，现代写法是这样的：
# 现代CMake 3.x+ 风格（推荐）
add_executable(app main.cpp)
target_include_directories(app PRIVATE ${CMAKE_SOURCE_DIR}/include)
target_compile_definitions(app PRIVATE ENABLE_LOG)
target_link_libraries(app PRIVATE math pthread)
add_executable(tools helper.cpp)
# tools 干干净净，不受任何牵连看到了吗？app的用料、工艺、依赖被封装在app自己的属性里。tools像是一个独立的承包商，它不需要关心隔壁app在干什么。这种目标级属性（Target Properties）的设计，让大型项目从”大锅饭”时代迈入了”责任制”时代。
要点2：避免使用全局变量
被现代CMake”拉黑”的三个命令
在现代CMake的最佳实践中，有三个曾经无处不在的命令被打上了_legacy（遗产）的标签：
include_directories()→ 请改用target_include_directories()link_libraries()→ 请改用target_link_libraries()add_definitions()→ 请改用target_compile_definitions()或target_compile_options()
注意，这些命令至今仍然有效，CMake并没有删除它们（为了向后兼容）。但优秀的CMake工程师会主动避开它们，就像有经验的厨师不会用生锈的刀——它能切菜，但迟早会出意外。
全局变量的三大罪状
为什么我们要对这三个”老前辈”如此绝情？因为它们犯了构建系统设计的三宗罪：
-
污染范围不可控
这些命令本质上修改的是目录属性（Directory Properties）。它们不仅影响当前
CMakeLists.txt中后续定义的所有目标，还会通过add_subdirectory()向下渗透。你可能在顶层目录 innocently 地写了一句add_definitions(-DUSE_DEPRECATED_API)，结果三个月后在底层某个模块里，一个完全无关的库因为这个宏定义编译失败了，而你根本想不到原因。 -
破坏封装性
好的软件设计讲究”高内聚、低耦合”。但在全局变量模式下，目标之间没有任何隐私可言。
app的头文件搜索路径、宏定义、链接库全部暴露在tools面前。这种强耦合让代码复用变得异常困难——当你想把tools拆出来给别的项目用时，会发现它莫名其妙地依赖了一堆自己根本不需要的东西。 -
难以调试和维护
当你的项目报错”找不到头文件”时，如果是现代CMake写法，你只需检查报错目标自己的
target_include_directories即可。但如果是老写法，你需要在层层叠叠的目录中，翻找每一处include_directories，像大海捞针一样排查到底是哪条命令在作祟。
一个真实的血泪教训
假设你有一个图像处理模块imgproc，它内部使用了stb_image库，而这个库要求定义STB_IMAGE_IMPLEMENTATION宏才能编译：
# 错误示范：全局宏定义
add_definitions(-DSTB_IMAGE_IMPLEMENTATION)
add_executable(viewer viewer.cpp)
target_link_libraries(viewer PRIVATE imgproc)问题在于：viewer本身可能也间接包含了stb_image.h，结果因为全局宏定义，viewer里的头文件也展开了实现代码，导致符号重复定义（Multiple Definition）的链接错误。正确的做法应该是：
# 正确示范：目标级宏定义
add_library(imgproc imgproc.cpp)
target_compile_definitions(imgproc PRIVATE STB_IMAGE_IMPLEMENTATION)
add_executable(viewer viewer.cpp)
target_link_libraries(viewer PRIVATE imgproc)这样，宏定义被严严实实地封在imgproc内部，viewer的世界清净了。
要点3：目标传递性（Transitivity）设计哲学
依赖的自动传播：Modern CMake的精髓
如果说”目标级属性”是现代CMake的骨架，那么传递性（Transitivity）就是它的血脉。这个机制让CMake从”高级版Makefile”真正进化成了”声明式依赖管理系统”。
在真实世界里，依赖往往是链式的：app依赖network库，network库又依赖ssl库，ssl库还依赖crypto库。在传统构建系统中，你需要手动把ssl和crypto都链接到app上，否则就会报错。这就像你要买一台电脑，卖家说：”主机卖给你，但显示器、电源线、鼠标你得自己分别找厂商买。”
现代CMake的传递性机制则优雅得多：你只需要告诉CMake”app直接依赖network“，至于network内部还需要什么，由network自己声明。CMake会像沿着藤蔓摘瓜一样，自动把间接依赖也处理好。
PUBLIC、PRIVATE、INTERFACE 的本质
我们在2.2节已经初步接触了这三个关键字，但在理念层面，它们代表着三种不同的契约关系：
-
PRIVATE —— “我自己用，不麻烦别人”
如果
network内部 privately 链接了log库，那么app在链接network时，不会被迫也链接log。log的头文件路径、宏定义也不会污染app的编译环境。这体现了良好的信息隐藏。 -
PUBLIC —— “我用，且我的使用者也需要”
如果
network的头文件里直接包含了ssl的头文件，那么任何使用network的目标（如app）在编译时也必须能找到ssl的头文件。此时network应该公开（PUBLIC）地依赖ssl，让这条需求自动传递给上游。 -
INTERFACE —— “我自己不用，但我的使用者需要”
这听起来有些反直觉，但在实际中非常常见。例如，你有一个纯头文件的C++标准库适配层，它本身不需要额外链接库，但使用它的目标必须开启
-std=c++17。此时你可以创建一个INTERFACE库来承载这个要求，它像一份使用说明书，自己不消耗材料，但要求下游按规矩办事。
传递性在代码中的魔力
让我们用一个三层依赖的例子，直观感受传递性的力量：
add_library(crypto STATIC crypto.cpp)
add_library(ssl STATIC ssl.cpp)
target_link_libraries(ssl PUBLIC crypto) # ssl的接口里暴露了crypto的类型
target_include_directories(ssl PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/ssl)
add_library(network STATIC network.cpp)
target_link_libraries(network PUBLIC ssl) # network的接口里暴露了ssl的类型
add_executable(app main.cpp)
target_link_libraries(app PRIVATE network) # 只需链接直接依赖！在这个例子中，app只显式链接了network。但由于network对ssl是PUBLIC依赖，ssl对crypto也是PUBLIC依赖，CMake会自动：
- 在编译
app时，把network、ssl的头文件目录都加入搜索路径； - 在链接
app时，把network、ssl、crypto三个库按正确顺序排列。
你不需要在app里写任何关于ssl或crypto的内容。这就是所谓的“只需关注直接依赖， transitive dependencies 自动处理”。这也是现代CMake相比其他许多构建系统最令人赏心悦目的设计之一。
小结：Modern CMake 的”第一性原理”
这节课我们并没有学习很多新的命令——target_link_libraries、target_include_directories你在前面已经见过了。但我们换了一个视角，理解了为什么要这样写。
现代CMake的核心可以浓缩成三句话：
- 以目标为中心（Target-centric）：所有构建信息应该属于某个目标，而不是飘在某个目录里。
- 拒绝全局污染（No Globals）：尽量不使用
include_directories、link_libraries、add_definitions，而是用target_前缀的命令精准投递。 - 尊重传递契约（Transitivity）：通过
PRIVATE、PUBLIC、INTERFACE显式声明依赖的边界，让依赖像水流一样自然传导，而不是像泥浆一样四处飞溅。
掌握了这套理念，你再看后续的接口库、生成器表达式、导出与安装，都会有一种”原来如此”的通透感。因为在Modern CMake的世界里，一切都是目标，一切目标都在讲述自己的需求（Usage Requirements）。而你，就是那个听得懂需求的优秀建筑师。
没有回复内容