8. 2.4 构建类型与配置

message(STATUS "Release C++ flags: ${CMAKE_CXX_FLAGS_RELEASE}")
# 输出示例（GCC）：-O3 -DNDEBUG

RelWithDebInfo：带调试信息的发布版

RelWithDebInfo（Release with Debug Information）是一种非常实用的折中方案。它启用适度的优化（通常是 -O2），但同时保留调试符号（-g）。

这种模式特别适合以下场景：

• 需要分析生产环境中的崩溃转储（Core Dump）。
• 使用性能分析工具（Profiler）时需要符号表来定位热点函数。
• 发布给QA团队进行最终测试，既保留接近真实的性能，又能在出现问题时调试。

message(STATUS "RelWithDebInfo C++ flags: ${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")
# 输出示例（GCC）：-O2 -g -DNDEBUG

MinSizeRel：最小体积优化

MinSizeRel 模式专注于生成体积最小的可执行文件或库，通常使用 -Os（GCC/Clang）或等效标志。它同样会定义 NDEBUG。

这个模式在以下场景非常有价值：

• 嵌入式系统，存储空间（ROM/Flash）极其有限。
• 容器镜像或移动端App，需要严格控制包体大小。
• 网络分发场景，希望减少下载体积。

message(STATUS "MinSizeRel C++ flags: ${CMAKE_CXX_FLAGS_MINSIZEREL}")
# 输出示例（GCC）：-Os -DNDEBUG

单配置生成器 vs 多配置生成器

这是CMake初学者最容易混淆的概念之一。生成器（Generator）不仅决定了你使用什么底层工具（Make、Ninja、Visual Studio）来编译，还直接决定了构建类型是在”配置时”决定，还是在”构建时”决定。

单配置生成器：Ninja与Unix Makefiles

单配置生成器（Single-Configuration Generators）包括 Unix Makefiles、Ninja 等。它们的特性是：

• 在配置阶段（cmake -B build）就必须通过 CMAKE_BUILD_TYPE 变量确定唯一的构建类型。
• 一个构建目录（build directory）只能存放一种配置。
• 如果你想同时持有Debug和Release版本，通常需要建立两个独立的构建目录。

# 创建 Debug 构建目录
cmake -B build-debug -DCMAKE_BUILD_TYPE=Debug -G Ninja .
cmake --build build-debug

# 创建 Release 构建目录
cmake -B build-release -DCMAKE_BUILD_TYPE=Release -G Ninja .
cmake --build build-release

在单配置生成器下，CMAKE_BUILD_TYPE 变量的值会直接影响CMake选择哪一组编译标志。如果你在配置时忘了设置它，CMake默认会使用空字符串（即不添加任何默认优化或调试标志），这往往不是你想要的结果。

因此，一个稳健的项目通常会在根CMakeLists.txt中做如下兜底处理：

# 仅针对单配置生成器设置默认值
if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
    set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the build type" FORCE)
    # 提供可选值给CMake GUI使用
    set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
        "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
endif()

多配置生成器：Visual Studio与Xcode

多配置生成器（Multi-Configuration Generators）包括 Visual Studio 17 2022、Xcode 以及 Ninja Multi-Config。它们的特性完全相反：

• 配置阶段不需要指定 CMAKE_BUILD_TYPE。实际上，设置这个变量对它们通常是无效的。
• CMake会一次性生成所有配置（Debug、Release、RelWithDebInfo、MinSizeRel）的工程文件。
• 你在构建阶段（cmake --build）才决定具体编译哪一种配置。

# 配置阶段（不指定构建类型）
cmake -B build -G "Visual Studio 17 2022" .

# 构建阶段选择配置
cmake --build build --config Debug
cmake --build build --config Release

多配置生成器通过 CMAKE_CONFIGURATION_TYPES 变量来控制要生成哪些配置。你可以修改这个变量来精简生成的配置列表：

# 只生成 Debug 和 Release，去掉 RelWithDebInfo 和 MinSizeRel
set(CMAKE_CONFIGURATION_TYPES "Debug;Release" CACHE STRING "" FORCE)

在多配置生成器环境下，CMakeLists.txt中不能依赖 CMAKE_BUILD_TYPE 的值来做逻辑判断，因为它在配置时可能是空的。这正是生成器表达式（Generator Expressions）大显身手的地方，我们会在下文详细讲解。

自定义构建类型

除了四大标准类型，CMake还允许你定义自己的构建类型，以满足特殊需求。例如，你可能需要一个 Profile 类型，专门用于性能分析（带 -pg 支持）。

自定义构建类型需要两个步骤：

1. 将新类型加入可选列表（对多配置生成器是 CMAKE_CONFIGURATION_TYPES，对单配置生成器则是在 CMAKE_BUILD_TYPE 的字符串属性中）。
2. 为新类型定义对应的编译器和链接器标志，遵循 CMAKE_<LANG>_FLAGS_<CONFIG> 和 CMAKE_<TYPE>_LINKER_FLAGS_<CONFIG> 的命名规范。

cmake_minimum_required(VERSION 3.20)
project(CustomBuildType)

# 步骤1：扩展配置列表（对多配置生成器有效）
set(CMAKE_CONFIGURATION_TYPES "Debug;Release;Profile" CACHE STRING "" FORCE)

# 步骤2：定义 Profile 类型的标志（以GCC/Clang为例）
set(CMAKE_CXX_FLAGS_PROFILE "-O2 -g -pg -fno-omit-frame-pointer" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_PROFILE   "-O2 -g -pg -fno-omit-frame-pointer" CACHE STRING "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS_PROFILE "-pg" CACHE STRING "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS_PROFILE "-pg" CACHE STRING "" FORCE)

add_executable(myapp main.cpp)

对于单配置生成器，你可以通过命令行直接启用自定义类型：

cmake -B build-profile -DCMAKE_BUILD_TYPE=Profile -G Ninja .
cmake --build build-profile

需要注意的是，自定义构建类型中的配置名必须是大写的（如 PROFILE），CMake在匹配标志变量时会自动将你在 CMAKE_BUILD_TYPE 中输入的值转换为大写去查找对应的 CMAKE_CXX_FLAGS_XXX。

基于构建类型的条件化配置

在实际项目中，我们往往需要根据构建类型执行不同的逻辑。例如：

• Debug模式下启用额外的断言和日志。
• Release模式下启用链接时优化（LTO/IPO）。
• 仅Debug模式下链接调试版本的第三方库。

传统方式：if 语句的局限性

很多初学者会写出这样的代码：

# 不推荐！尤其在多配置生成器下会失效
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    target_compile_definitions(myapp PRIVATE ENABLE_VERBOSE_LOG)
endif()

这段代码在单配置生成器（如Ninja）下可以工作，但在多配置生成器（如Visual Studio）下会完全失效。因为多配置生成器在配置时 CMAKE_BUILD_TYPE 为空，if 条件永远不会成立，导致你在Visual Studio里切换Debug配置时，ENABLE_VERBOSE_LOG 根本就没有被定义。

现代方式：使用生成器表达式

正确的做法是使用生成器表达式（Generator Expressions），特别是 $<CONFIG:...>。它的值会在构建阶段根据你选择的配置动态解析，完美兼容单配置和多配置生成器。

add_executable(myapp main.cpp)

# 根据不同的构建类型添加不同的编译定义
target_compile_definitions(myapp PRIVATE
    $<$:DEBUG_MODE>
    $<$:ENABLE_ASSERTS>
    $<$:RELEASE_MODE>
    $<$:REL_DEB_MODE>
)

# 根据不同的构建类型添加不同的编译选项
target_compile_options(myapp PRIVATE
    $<$:-O0 -g3 -Wall>
    $<$:-O3 -march=native>
    $<$:-Os>
    $<$:-O2 -g>
)

# 条件化链接库：Debug 链接调试版库，Release 链接发布版库
target_link_libraries(myapp PRIVATE
    $<$:libfoo_d>
    $<$:libfoo>
)

这里解释一下语法：$<CONFIG:Debug> 是一个条件表达式。如果当前构建类型是Debug，它会被替换为 1（真），否则替换为空字符串（假）。外层 $<$<CONFIG:Debug>:-O0 -g3> 则是一个”条件-值”表达式：如果内层条件为真，则输出 -O0 -g3，否则输出空。

对于链接器选项，同样可以使用 target_link_options：

target_link_options(myapp PRIVATE
    $<$:-flto=auto>
    $<$:-rdynamic>
)

更复杂的逻辑组合

生成器表达式还支持逻辑与（$<AND:>）、逻辑或（$<OR:>）等操作，可以处理更复杂的场景。例如，只有在Debug且使用GCC时才启用某一项检查：

target_compile_options(myapp PRIVATE
    $<$<AND:$,$>:-fstack-protector-all>
)

完整实战示例

下面是一个综合了本节所有知识点的完整CMakeLists.txt示例，展示如何优雅地管理构建类型：

cmake_minimum_required(VERSION 3.20)
project(BuildTypePractice VERSION 1.0.0 LANGUAGES CXX)

# ---- 1. 设置默认构建类型（仅单配置生成器） ----
if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
    set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "Build type" FORCE)
    set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
        "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
endif()

# ---- 2. 对多配置生成器精简配置列表 ----
set(CMAKE_CONFIGURATION_TYPES "Debug;Release;RelWithDebInfo" CACHE STRING "" FORCE)

# ---- 3. 创建目标 ----
add_executable(calc src/main.cpp src/math.cpp)

# ---- 4. 统一设置 C++ 标准 ----
target_compile_features(calc PRIVATE cxx_std_17)

# ---- 5. 基于配置类型的现代条件化配置 ----
target_compile_definitions(calc PRIVATE
    $<$:CALC_ENABLE_LOGGING>
    $<$:CALC_ENABLE_SAFETY_CHECKS>
    $<$:CALC_OPTIMIZED>
)

target_compile_options(calc PRIVATE
    # Debug: 最大调试信息，严格警告
    $<$:-O0 -g3 -Wall -Wextra -Wpedantic>
    
    # Release: 高级优化，丢弃符号（对GCC而言，Release默认不含-g）
    $<$:-O3>
    
    # RelWithDebInfo: 适度优化+符号
    $<$:-O2 -g>
)

# ---- 6. 配置特定链接选项（如 LTO） ----
include(CheckIPOSupported)
check_ipo_supported(RESULT ipo_supported OUTPUT error)
if(ipo_supported)
    set_property(TARGET calc PROPERTY INTERPROCEDURAL_OPTIMIZATION_RELEASE TRUE)
    set_property(TARGET calc PROPERTY INTERPROCEDURAL_OPTIMIZATION_RELWITHDEBINFO TRUE)
endif()

# ---- 7. 打印当前配置信息 ----
message(STATUS "Generator: ${CMAKE_GENERATOR}")
message(STATUS "C++ Compiler: ${CMAKE_CXX_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION}")
if(CMAKE_BUILD_TYPE)
    message(STATUS "Build Type (single-config): ${CMAKE_BUILD_TYPE}")
else()
    message(STATUS "Build Types (multi-config): ${CMAKE_CONFIGURATION_TYPES}")
endif()

本节小结与最佳实践

• 理解四大标准类型：Debug（调试用）、Release（发布用）、RelWithDebInfo（带符号的发布）、MinSizeRel（最小体积）。
• 区分单/多配置生成器：Ninja/Make在配置时选类型（-DCMAKE_BUILD_TYPE）；Visual Studio/Xcode在构建时选类型（--config）。
• 永远不要假设 CMAKE_BUILD_TYPE 一定有值。做多配置判断时，务必使用生成器表达式 $<CONFIG:...>。
• 显式设置默认值：对于单配置生成器，在根CMakeLists.txt中检测 NOT CMAKE_BUILD_TYPE 并设置一个合理的默认值（通常是 RelWithDebInfo 或 Release）。
• 自定义构建类型需谨慎：虽然CMake支持自定义配置，但过度使用会降低项目的可维护性。优先尝试用生成器表达式解决条件化需求，而非创造新的构建类型。

掌握了构建类型的精髓，你就能够像专业工程师一样，让同一个CMake项目在”开发态”和”生产态”之间游刃有余地切换。下一节，我们将正式进入现代CMake（Modern CMake）的核心理念——从目录级变量到目标级属性的范式转变。