10、生成器表达式基础：语法、布尔与字符串表达式
生成器表达式，是 CMake 里一个非常核心但又容易让人困惑的概念。我第一次接触它的时候，心里想的是：「这玩意儿不就是个三目运算符吗？」后来用多了才发现，它远不止这么简单。
说白了，生成器表达式是一种在构建系统生成阶段才求值的机制。什么意思呢？就是 CMake 在解析你的 CMakeLists.txt 时，并不会立刻计算它的值，而是等到生成构建系统（比如 Makefile 或 Ninja 文件）的时候，才根据当时的上下文去计算。嗯，这一点非常关键，很多坑都是从这里来的。
核心要点：生成器表达式用 $<...> 包裹，内部可以嵌套、组合，最终在生成阶段求值。
10.1 基本语法：$<...>
语法很简单，就是 $<expression>。但这里的 expression 可以是布尔表达式、字符串表达式，或者配置相关的表达式。我习惯把生成器表达式分成三类：
- 布尔生成器表达式：返回 0 或 1，用于条件判断。
- 字符串生成器表达式：返回一个字符串，用于拼接路径、标志等。
- 配置相关表达式：与构建类型、平台、编译器相关的表达式。
你可能会问：「为什么不用普通的 if 语句？」因为有些信息在 CMake 解析阶段是未知的。比如，同一个目标可能被多个配置使用（Debug 和 Release），它们的编译选项不同。这时候，生成器表达式就派上用场了。
10.2 布尔生成器表达式
布尔生成器表达式返回 0 或 1。最常见的用法是 $<BOOL:...>，它会将后面的值转换为布尔值。空字符串、0、OFF、NO、FALSE、N、IGNORE、NOTFOUND 等都会被视为假，其他为真。
# 示例：根据条件添加编译定义
target_compile_definitions(my_target PRIVATE
$<$<BOOL:${USE_FEATURE_X}>:USE_FEATURE_X>
)这里有个嵌套结构：外层 $<...> 是条件表达式，内层 $<BOOL:...> 是布尔判断。如果 USE_FEATURE_X 为真，则添加 USE_FEATURE_X 宏定义；否则什么都不加。
个人经验：我在项目中遇到过一种情况：有人用 if(USE_FEATURE_X) 包裹整个 target_compile_definitions，结果在 multi-config 生成器（比如 Xcode）下，不同配置的宏定义居然不一致。改用生成器表达式后，问题就解决了。
常用的布尔生成器表达式还有：
| 表达式 | 说明 |
|---|---|
$<BOOL:string> |
将字符串转为布尔值 |
$<NOT:expr> |
逻辑非 |
$<AND:expr1,expr2,...> |
逻辑与（所有为真才真） |
$<OR:expr1,expr2,...> |
逻辑或（任一为真即真） |
10.3 字符串生成器表达式
字符串生成器表达式，说白了就是根据条件返回不同的字符串。最常见的格式是：
$<condition:true_string>如果 condition 为真，则返回 true_string；否则返回空字符串。这有点像 C 语言里的 condition ? "true_string" : ""。
举个例子：
# 根据构建类型添加不同的编译选项
target_compile_options(my_target PRIVATE
$<$<CONFIG:Debug>:-g -O0>
$<$<CONFIG:Release>:-O3 -DNDEBUG>
)这里 $<CONFIG:Debug> 是一个配置相关的布尔表达式，如果当前构建类型是 Debug，则返回 1，否则返回 0。然后外层 $<...> 根据这个布尔值决定是否返回后面的字符串。
避坑指南：我曾经在项目里看到有人这样写：$<Debug>:-g。这是错误的！$<Debug> 并不是一个合法的生成器表达式。正确的写法是 $<$<CONFIG:Debug>:-g>。记住，条件部分必须是一个布尔生成器表达式。
字符串生成器表达式还可以嵌套：
# 根据平台和配置选择不同的库
target_link_libraries(my_target PRIVATE
$<$<AND:$<PLATFORM_ID:Linux>,$<CONFIG:Debug>>:linux_debug_lib>
$<$<AND:$<PLATFORM_ID:Linux>,$<CONFIG:Release>>:linux_release_lib>
)嗯，这里用到了 $<AND:...> 来组合多个条件。虽然看起来有点复杂，但逻辑很清晰：只有在 Linux 平台且是 Debug 构建时，才链接 linux_debug_lib。
10.4 配置相关表达式
配置相关表达式是生成器表达式里最常用的一类。它们能获取当前构建的配置信息，比如构建类型、平台、编译器等等。
常用的配置相关表达式：
| 表达式 | 说明 |
|---|---|
$<CONFIG:cfg> |
当前构建类型是否为 cfg（如 Debug、Release） |
$<PLATFORM_ID:platform> |
当前平台是否为 platform（如 Linux、Windows、Darwin） |
$<COMPILE_LANGUAGE:lang> |
当前编译语言是否为 lang（如 CXX、C） |
$<TARGET_EXISTS:target> |
目标 target 是否存在 |
$<LINK_LANGUAGE:lang> |
当前链接语言是否为 lang |
举个例子，假设你有一个项目，需要在不同平台上链接不同的库：
target_link_libraries(my_target PRIVATE
$<$<PLATFORM_ID:Windows>:ws2_32>
$<$<PLATFORM_ID:Linux>:pthread>
)这样，在 Windows 上链接 ws2_32，在 Linux 上链接 pthread。干净利落，不需要写一堆 if(WIN32) 和 if(UNIX)。
个人习惯：我一般会把平台相关的生成器表达式放在一个单独的变量里，比如 set(platform_libs $<$<PLATFORM_ID:Windows>:ws2_32> $<$<PLATFORM_ID:Linux>:pthread>)，然后在 target_link_libraries 里直接引用这个变量。这样代码更清晰，也方便维护。
10.5 知识体系总览
下面这张图总结了生成器表达式的核心分类和关系：
10.6 实际应用中的注意事项
生成器表达式虽然强大，但用起来也有一些需要注意的地方：
- 不要滥用：如果条件在 CMake 解析阶段就能确定，直接用
if()更清晰。生成器表达式适合那些「运行时才能确定」的场景。 - 注意嵌套层次：嵌套太多层，代码可读性会急剧下降。我一般最多嵌套两层，超过两层就考虑拆分成变量。
- 调试技巧：可以用
message()打印生成器表达式的结果吗？不行，因为生成器表达式在生成阶段才求值。你可以用file(GENERATE ...)将结果写入文件来调试。
我曾经踩过的坑：有一次我在 target_include_directories 里用了生成器表达式，结果发现头文件路径在 IDE 里显示不出来。原因是某些 IDE（比如 Visual Studio）在解析项目文件时，并不会完全求值生成器表达式。解决方案是：对于 IDE 必须可见的路径，用普通的变量传递，不要用生成器表达式。
好了，生成器表达式的基础就讲到这里。说白了，它就是 CMake 里的一种「延迟求值」机制，让你能在构建系统生成阶段根据上下文做出决策。掌握了它，你的 CMake 脚本会变得更加灵活和强大。