告别变量地狱：目标导向思想才是现代CMake的灵魂
说实话，我第一次接触CMake的时候，差点被那些密密麻麻的变量搞疯掉。
那时候的项目里，CMakeLists.txt长这样：
set(SOURCES src/main.cpp src/utils.cpp src/network.cpp)
set(INCLUDE_DIRS include /usr/local/include)
set(LIBS pthread ssl crypto)
add_executable(my_app ${SOURCES})
target_include_directories(my_app PRIVATE ${INCLUDE_DIRS})
target_link_libraries(my_app ${LIBS})
看着还行对吧？但项目一大了，变量满天飞。你根本不知道某个变量是在哪里定义的，被谁修改过，最后用在了哪里。我管这叫「变量地狱」。
后来CMake 3.x引入了目标导向思想，说白了就是——别折腾变量了，直接操作目标本身。
什么是「目标」？
目标（Target）就是你要构建的东西。它可以是：
- 一个可执行文件（
add_executable） - 一个库（
add_library） - 一个自定义目标（
add_custom_target）
每个目标都有自己的属性：源文件、头文件路径、链接库、编译选项、宏定义……
你想想看，这就像一个人。人有名字、身高、体重、爱好。目标也有名字、源文件、依赖、属性。你不需要把一个人的所有信息写在黑板上到处传递，你只需要认识这个人，直接问他。
核心思想： 把构建信息绑定到目标上，而不是散落在全局变量里。
add_executable：定义可执行文件目标
语法很简单：
add_executable(<name> [source1 source2 ...])
这会创建一个名为<name>的可执行文件目标。源文件列表可以后续通过target_sources添加。
我个人习惯这样写：
add_executable(my_app)
target_sources(my_app PRIVATE
src/main.cpp
src/utils.cpp
src/network.cpp
)
为什么分开写？因为这样更清晰。源文件是目标的「私有财产」，用PRIVATE修饰，表示这些源文件只属于这个目标，不会泄露给依赖它的其他目标。
小技巧： 用target_sources代替在add_executable里列源文件，方便后续用条件语句动态添加源文件。
add_library：定义库目标
库目标有三种类型：
| 类型 | 说明 | 典型场景 |
|---|---|---|
STATIC |
静态库（.a / .lib） | 内部模块，不想暴露实现 |
SHARED |
动态库（.so / .dll） | 插件系统、公共接口 |
MODULE |
插件库（不直接链接） | 运行时动态加载 |
举个例子：
add_library(core STATIC)
target_sources(core PRIVATE
src/core.cpp
src/algorithm.cpp
)
target_include_directories(core PUBLIC include)
这里有个关键点： 嗯，这里要注意： 我画了一张图，帮你理解传统方式和目标方式的区别： 看到了吗？左边是变量满天飞，右边是属性绑定到目标。哪个更清晰，一目了然。 目标导向最强大的地方在于：依赖自动传递。 假设你有三个目标： 这里发生了什么？ 这就是目标导向的威力——依赖链自动管理。 避坑指南： 我曾经在一个项目里，因为用了 这是目标导向里最核心的概念之一。我再用一个表格帮你理清： 举个例子：你写了一个数学库，头文件暴露了 这样设计，下游只需要链接你的库，所有依赖自动搞定。 我参与过一个老项目，CMakeLists.txt有800多行，全是 迁移到目标导向后，变成了这样： 你发现没有？每个目标只关心自己的事情。依赖关系通过 个人建议： 新项目一律用目标导向。老项目迁移时，从最底层的库开始，逐层往上改。不要一次性全改，容易出问题。 目标导向思想说白了就是一句话：把构建信息绑定到目标上，让目标自己管理自己。 我记得刚学会目标导向那会儿，回头再看老代码，简直不忍直视。变量地狱不是开玩笑的——你永远不知道一个变量从哪里来，到哪里去。而目标导向，让一切变得清晰、可控、可维护。 嗯，这就是现代CMake的核心。掌握了它，你的CMakeLists.txt会变得像乐高积木一样，每个目标都是一个独立的模块，拼在一起就是一个完整的项目。PUBLIC。它表示include目录不仅对core自己可见，对任何链接core
PUBLIC和PRIVATE的区别，是目标导向思想里最容易搞混的地方。我刚开始也踩过坑。为什么目标导向是核心？
目标之间的依赖关系
add_library(utils STATIC)
target_include_directories(utils PUBLIC include/utils)
target_sources(utils PRIVATE src/string_utils.cpp)
add_library(core STATIC)
target_include_directories(core PUBLIC include/core)
target_sources(core PRIVATE src/core.cpp)
target_link_libraries(core PUBLIC utils)
add_executable(my_app)
target_sources(my_app PRIVATE src/main.cpp)
target_link_libraries(my_app PRIVATE core)
my_app链接了core，所以自动获得了core的PUBLIC头文件路径core链接了utils，且是PUBLIC，所以my_app也自动获得了utils的头文件路径my_app的INCLUDE_DIRS变量PRIVATE链接了一个库，结果下游目标死活找不到头文件。排查了半天才发现是可见性设错了。记住：PUBLIC = 自己用 + 下游用；PRIVATE = 只有自己用；INTERFACE = 只有下游用（比如纯头文件库）。目标属性的可见性
关键字
对自己可见
对下游可见
典型用途
PRIVATE✅
❌
内部实现细节
PUBLIC✅
✅
接口头文件、公开依赖
INTERFACE❌
✅
纯头文件库、接口定义
add()函数，但内部用了boost::multiprecision做高精度计算。
boost::multiprecision应该是PRIVATE的——下游不需要知道PUBLIC的——下游需要#include从变量到目标：一个实际迁移案例
set()和add_subdirectory()。每次加一个新模块，都要手动维护一堆变量。# 每个模块一个目标
add_library(module_a STATIC)
target_sources(module_a PRIVATE src/a.cpp)
target_include_directories(module_a PUBLIC include)
target_link_libraries(module_a PUBLIC common_lib)
add_library(module_b STATIC)
target_sources(module_b PRIVATE src/b.cpp)
target_include_directories(module_b PUBLIC include)
target_link_libraries(module_b PUBLIC module_a)
add_executable(main_app)
target_sources(main_app PRIVATE src/main.cpp)
target_link_libraries(main_app PRIVATE module_b)
target_link_libraries自动传递。不需要全局变量，不需要手动拼接路径。总结一下
add_executable和add_library定义目标target_xxx系列命令给目标添加属性PUBLIC/PRIVATE/INTERFACE控制可见性