target_sources()用于向已创建的目标动态添加源文件，支持private/public/interface作用域控制，实现模块化管理、条件编译和延迟绑定。
target 就是构建产物的抽象容器
它不是文件，也不是目录，而是一个逻辑单元——代表你最终想要的东西：一个可执行文件、一个库、或者一个自定义动作（比如生成配置文件）。CMake 用 add_executable()、add_library() 或 add_custom_target() 创建它，之后所有编译选项、头文件路径、链接库都必须挂在这个 target 上，而不是全局设置。
常见误解是把 target 当成“源文件集合”，但其实它更接近“构建契约”：你声明“我要产出 myapp”，CMake 就负责确保所有依赖（源码、头文件、链接库、编译定义）都正确就位，并按需重建。一旦定义，就不能再往里“追加”源文件（除非用 target_sources()），也不能靠修改变量间接影响它。
为什么不能直接写 include_directories()？
因为 include_directories() 是全局命令，它会让所有后续定义的 target 都看到这些路径——这会污染依赖关系，导致不该编译通过的 target 也意外通过，或者掩盖头文件路径缺失的真实问题。
正确做法是用 target_include_directories()，并明确作用域：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
PUBLIC：这个 target 自己要用，且任何链接它的 target（比如可执行文件链接静态库）也要用 —— 适合库的 public 头路径 -
PRIVATE：只给自己用，不传递 —— 适合内部实现头文件 -
INTERFACE：自己不用，但链接它的 target 必须用 —— 适合纯头文件库或生成的头路径（如${CMAKE_BINARY_DIR}/generated）
target_sources() 解决什么实际问题？
当项目目录变深、源文件分散在 src/core/、src/network/、third_party/xyz/ 时，硬编码在 add_executable(myapp ...) 里既难维护又易漏文件。这时候 target_sources() 就派上用场：
- 它允许你在子目录的
CMakeLists.txt中直接为上级 target 添加源文件，比如：target_sources(myapp PRIVATE network/tcp.cpp) - 支持
FILE_SET（CMake 3.23+）管理生成的头/源文件，比如 protobuf 自动生成的pb.cc - 避免用
aux_source_directory()这种“扫描即添加”的危险方式——它可能误吞测试文件或临时文件
target 名字不是随便起的
名字会出现在构建命令、链接语句、IDE 项目结构里，还影响依赖解析。几个关键约束：
- 不能和已有 target 同名，否则 CMake 报错：
add_executable() called with incorrect number of arguments - 不能包含空格或特殊字符（如
my-app在某些生成器下会失败，应改用my_app） - 如果用了
EXCLUDE_FROM_ALL，必须显式构建：cmake --build . -t mytool，否则不会出现在默认all目标里 - 名字大小写敏感，
MyLib和mylib是两个不同 target，链接时写错就报target not found
真正容易被忽略的是：target 名字一旦在 target_link_libraries() 中引用，就必须在当前作用域已定义——跨目录引用时，必须确保 add_library() 出现在 target_link_libraries() 之前，否则 CMake 不认。
