24、多配置生成器：理解CMAKE_CONFIGURATION_TYPES、为Debug/Release分别打包、CPACK_CONFIG_FILE

说实话，多配置生成器这个话题，我当年刚接触CMake时也绕了不少弯路。Visual Studio和Xcode这类IDE，它们不像Makefile那样一次只生成一种配置——它们天生就支持Debug、Release、RelWithDebInfo等多种配置共存。你想想看，在同一个项目里同时保留调试信息和优化后的二进制，这多方便啊。但方便归方便，打包的时候就容易出幺蛾子了。

理解CMAKE_CONFIGURATION_TYPES

这个变量，说白了就是告诉CMake：「嘿，我这个项目支持哪些构建类型」。对于Visual Studio这种多配置生成器，它默认就是Debug;Release;MinSizeRel;RelWithDebInfo。但说实话，我大部分项目只需要Debug和Release就够了。

我在项目中遇到过这样的情况：团队里有人用VS，有人用Ninja。结果Ninja那边死活不认CMAKE_CONFIGURATION_TYPES，折腾了半天才发现是生成器类型的问题。嗯，这里要注意——如果你用Ninja Multi-Config，那它也是多配置生成器，但传统的Ninja不是。

# 只保留Debug和Release
set(CMAKE_CONFIGURATION_TYPES "Debug;Release" CACHE STRING "" FORCE)

# 或者更激进一点，只保留Release
set(CMAKE_CONFIGURATION_TYPES "Release" CACHE STRING "" FORCE)

我个人习惯在项目根CMakeLists.txt里尽早设置这个变量。为什么？因为一旦项目开始处理target，再改配置类型就可能出问题。我曾经吃过这个亏——在add_executable之后才设置，结果VS里死活看不到Debug配置。

为Debug/Release分别打包

打包这件事，Debug和Release的需求完全不同。Debug包通常要带调试符号、PDB文件、甚至未优化的代码。Release包则要精简、要优化、要剥离符号。你想想看，如果把Debug的PDB文件塞进Release包，那用户下载个几百兆的包结果发现是调试版，这体验多糟糕。

我的做法是这样的：

# 在CPack配置中判断当前配置
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-${PROJECT_VERSION}-Debug")
    install(TARGETS myapp
        CONFIGURATIONS Debug
        RUNTIME DESTINATION bin
        )
elseif(CMAKE_BUILD_TYPE STREQUAL "Release")
    set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-${PROJECT_VERSION}-Release")
    install(TARGETS myapp
        CONFIGURATIONS Release
        RUNTIME DESTINATION bin
        )
endif()

等等，这里有个坑。对于多配置生成器，CMAKE_BUILD_TYPE在构建时是空的！它只在单配置生成器里才有值。那怎么办？用CONFIGURATIONS参数来控制安装行为。

正确的做法是这样：

# 为不同配置分别指定安装规则
install(TARGETS myapp
    CONFIGURATIONS Debug
    RUNTIME DESTINATION bin/Debug
    )

install(TARGETS myapp
    CONFIGURATIONS Release
    RUNTIME DESTINATION bin/Release
    )

# 在CPack中根据配置打包
set(CPACK_INSTALL_CMAKE_PROJECTS
    "${CMAKE_BINARY_DIR};myproject;Debug;/"
    "${CMAKE_BINARY_DIR};myproject;Release;/"
    )

这样，Debug和Release的二进制就会安装到不同目录，打包时也能区分开。我记得有一次帮客户排查问题，他们就是把Debug和Release的DLL混在一起了，结果程序跑起来各种崩溃。后来用这种分目录安装的方式，问题就解决了。

CPACK_CONFIG_FILE的使用

这个变量，说实话用的人不多，但用好了非常强大。CPACK_CONFIG_FILE允许你为每个配置指定不同的CPack配置文件。什么意思呢？就是Debug和Release可以用完全不同的打包逻辑。

# 在CMakeLists.txt中
set(CPACK_CONFIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/cmake/CPackConfig.cmake")

# 在CPackConfig.cmake中
if(CPACK_BUILD_CONFIG STREQUAL "Debug")
    include("${CMAKE_CURRENT_SOURCE_DIR}/cmake/CPackDebug.cmake")
elseif(CPACK_BUILD_CONFIG STREQUAL "Release")
    include("${CMAKE_CURRENT_SOURCE_DIR}/cmake/CPackRelease.cmake")
endif()

我个人习惯把不同配置的打包参数拆到单独文件里。比如Debug包要包含PDB文件：

# CPackDebug.cmake
set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-${PROJECT_VERSION}-debug")
set(CPACK_NSIS_DEFINES "!include DebugIncludes.nsh")
install(FILES ${PDB_FILES} DESTINATION bin CONFIGURATIONS Debug)

而Release包则要签名和压缩：

# CPackRelease.cmake
set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-${PROJECT_VERSION}")
set(CPACK_NSIS_DEFINES "!include ReleaseIncludes.nsh")
set(CPACK_STRIP_FILES TRUE)
set(CPACK_INSTALL_STRIPPED TRUE)

知识体系结构图

实际项目中的最佳实践

说了这么多理论，来点实际的。我最近一个项目是这样组织的：

1. 项目根CMakeLists.txt：尽早设置CMAKE_CONFIGURATION_TYPES，只保留Debug和Release
2. 安装规则：用CONFIGURATIONS关键字区分不同配置的安装目标
3. CPack配置：用CPACK_CONFIG_FILE指向一个主配置文件，里面根据CPACK_BUILD_CONFIG加载不同子文件
4. 打包脚本：分别调用cpack -C Debug和cpack -C Release生成两个独立的安装包

# 打包命令示例
mkdir build && cd build
cmake .. -G "Visual Studio 17 2022"
cmake --build . --config Debug
cpack -C Debug
cmake --build . --config Release
cpack -C Release

这样生成的MyApp-1.0.0-Debug.exe和MyApp-1.0.0-Release.exe就完全分开了。用户下载Debug版可以调试，下载Release版直接使用，互不干扰。

嗯，最后提醒一句——千万别在CMAKE_BUILD_TYPE上翻车。多配置生成器下它就是个空字符串，老老实实用CONFIGURATIONS才是正道。

---