10、生成器表达式：$<...>的魔法。条件编译、平台判断、配置相关逻辑，让CMake代码更智能。

说实话，刚接触CMake那会儿，我看到 $<...> 这种语法，第一反应是——这什么鬼？尖括号里面套美元符号，看着就不像正经代码。后来在项目里被各种平台差异、编译配置折腾得够呛，才真正体会到这东西有多香。

生成器表达式，说白了就是CMake在生成构建系统（比如Makefile或Ninja文件）时才求值的表达式。它不像普通变量那样在 CMakeLists.txt 解析时就展开，而是延迟到最后一刻。这个特性让它能处理那些「不到编译时不知道」的条件逻辑。

10.1 为什么需要生成器表达式？

先看一个我踩过的坑。几年前做一个跨平台库，需要在Windows上导出DLL符号，Linux上则不需要。我一开始这么写：

if(WIN32)
    target_compile_definitions(mylib PRIVATE MYLIB_EXPORT)
endif()

看起来没问题对吧？但问题在于，如果 mylib 被其他项目通过 FetchContent 或 add_subdirectory 引入，WIN32 这个变量在配置阶段就已经确定了。可如果我想针对同一个目标的不同配置（比如Debug和Release）设置不同的宏呢？普通if语句就无能为力了。

生成器表达式就是为这种场景设计的。它支持：

• 条件编译：根据编译器、平台、配置等条件添加宏或源文件
• 平台判断：区分Windows、Linux、macOS、Android等
• 配置相关逻辑：Debug vs Release，静态库 vs 动态库
• 目标属性查询：获取目标的输出名称、位置、依赖关系等

10.2 基本语法与常用表达式

生成器表达式的通用格式是 $<condition:value>。如果条件为真，就输出 value，否则输出空字符串。来看几个最常用的：

表达式	含义	示例
$<CONFIG>	当前构建配置（Debug/Release等）	$<CONFIG> → "Debug"
$<PLATFORM_ID>	当前平台标识符	$<PLATFORM_ID> → "Windows"
$<BOOL:...>	布尔条件判断	$<$<CONFIG:Debug>:DEBUG_MODE>
$<TARGET_FILE:tgt>	目标tgt的输出文件路径	$<TARGET_FILE:myapp>
$<COMPILE_LANGUAGE>	当前编译语言（C/CXX等）	$<COMPILE_LANGUAGE> → "CXX"

我个人习惯把生成器表达式分成三类：信息查询类、条件判断类、字符串操作类。信息查询类就是上面表格里那些直接返回值的；条件判断类需要嵌套使用，比如 $<$<CONFIG:Debug>:my_debug_flag>；字符串操作类则用于拼接、替换等。

10.3 实战：条件编译与平台判断

回到刚才的DLL导出问题。用生成器表达式可以优雅解决：

target_compile_definitions(mylib PRIVATE
    $<$<PLATFORM_ID:Windows>:MYLIB_EXPORT>
)

这行代码的意思是：如果当前平台是Windows，就定义 MYLIB_EXPORT 宏；否则什么都不做。干净利落，而且不需要if语句。

再比如，我想在Debug模式下启用断言，Release模式下禁用：

target_compile_definitions(mylib PRIVATE
    $<$<CONFIG:Debug>:ENABLE_ASSERTS>
    $<$<CONFIG:Release>:NDEBUG>
)

嗯，这里要注意：NDEBUG 是C标准中控制 assert() 宏的，Release模式下通常需要定义它。但如果你用MSVC编译器，它可能已经自动帮你定义了。所以更稳妥的做法是结合编译器判断：

target_compile_definitions(mylib PRIVATE
    $<$<AND:$<CONFIG:Release>,$<NOT:$<CXX_COMPILER_ID:MSVC>>>:NDEBUG>
)

这个嵌套看着有点吓人，但拆开看其实很简单：$<AND:...> 要求两个条件同时为真——当前是Release配置，并且编译器不是MSVC。只有满足这两个条件，才定义 NDEBUG。

10.4 源文件的条件编译

有时候不同平台需要不同的源文件。比如Windows上用 win_socket.cpp，Linux上用 linux_socket.cpp。用生成器表达式可以这样：

target_sources(mynet PRIVATE
    $<$<PLATFORM_ID:Windows>:win_socket.cpp>
    $<$<PLATFORM_ID:Linux>:linux_socket.cpp>
    $<$<PLATFORM_ID:Darwin>:mac_socket.cpp>
)

这样CMake在生成构建系统时，只会把当前平台对应的源文件加入编译。其他文件根本不会出现在构建规则里，避免了无谓的编译错误。

我曾经在一个项目里看到有人用 if(WIN32) 加 set(SOURCES ...) 的方式处理这个问题。结果后来项目需要支持Android，又加了一层 if(ANDROID)，整个 CMakeLists.txt 变得又臭又长。用生成器表达式，所有条件都集中在一个 target_sources 调用里，清晰多了。

10.5 配置相关的链接库

链接库也经常需要区分配置。比如Debug模式下链接带调试符号的库，Release模式下链接优化过的库：

target_link_libraries(myapp PRIVATE
    $<$<CONFIG:Debug>:mylib_d>
    $<$<CONFIG:Release>:mylib>
)

或者更常见的，某些第三方库只在特定平台上可用：

target_link_libraries(myapp PRIVATE
    $<$<PLATFORM_ID:Windows>:ws2_32>
    $<$<PLATFORM_ID:Linux>:pthread>
)

你看，这样写出来，每个平台的依赖一目了然。维护起来也方便——想加一个macOS的依赖，直接加一行 $<$<PLATFORM_ID:Darwin>:...> 就行。

10.6 生成器表达式的嵌套与组合

生成器表达式可以嵌套，这是它最强大的地方。来看一个稍微复杂点的例子：

target_compile_options(mylib PRIVATE
    $<$<AND:$<CXX_COMPILER_ID:GNU>,$<CONFIG:Release>>:-O3>
    $<$<AND:$<CXX_COMPILER_ID:Clang>,$<CONFIG:Release>>:-O2>
)

这个意思是：如果用的是GCC并且是Release模式，加 -O3 优化；如果是Clang并且Release模式，加 -O2。为什么Clang只用 -O2？嗯，我在项目里实测过，Clang的 -O3 在某些场景下反而会生成更慢的代码，所以保守一点。

10.7 知识体系总览

下面这张图总结了生成器表达式的核心知识结构，我建议你保存下来，写CMake时对照着用：

10.8 避坑指南

最后分享几个我踩过的坑：

• 不要混淆生成器表达式和普通变量：$<CONFIG> 和 ${CMAKE_BUILD_TYPE} 不是一回事。前者在生成阶段求值，后者在配置阶段求值。如果你在 add_custom_command 里用 ${CMAKE_BUILD_TYPE}，可能拿到的是空值（因为多配置生成器如Visual Studio没有这个变量）。
• 生成器表达式不能用于文件操作：比如 file(READ ...) 或 configure_file() 中不能用生成器表达式，因为这些命令在配置阶段执行。
• 嵌套过多时用注释：我曾经写过一个四层嵌套的生成器表达式，两周后自己都看不懂了。现在我会在复杂表达式上方加一行注释，说明这个表达式在做什么。
• 测试你的表达式：可以用 message(STATUS "test: $<$<CONFIG:Debug>:DEBUG>") 来验证表达式是否按预期工作。注意，message() 在配置阶段执行，所以它只能展示生成器表达式的文本形式，不会真正求值。要真正测试，得用 add_custom_target 配合 COMMAND 来输出。

生成器表达式是CMake从「脚本语言」走向「构建系统描述语言」的关键特性。它让CMake代码变得更智能、更简洁。刚开始用的时候可能会觉得语法别扭，但一旦习惯了，你会发现很多以前需要写一堆if-else的逻辑，现在一行表达式就搞定了。

---