18、错误与警告控制：配置 CMAKE_WARN_DEPRECATED 等编译选项
说实话，CMake 的警告和错误控制，很多人一开始都不太在意。我早期带团队的时候也是这样——只要代码能编译通过，谁管那些黄色警告啊？直到有一次，一个同事升级了 CMake 版本，整个项目突然报了几百个 deprecated 警告，编译日志刷了整整三屏。嗯，从那以后，我就开始认真研究怎么管好这些「小喇叭」了。
为什么需要控制警告和错误？
你想想看，CMake 本身也是一个不断进化的工具。新版本会淘汰旧特性，引入新机制。如果你的项目里还用了老掉牙的写法，CMake 就会通过警告告诉你：「嘿，这玩意儿快不能用了，赶紧改吧。」
但问题是——
- 警告太多：真正的错误被淹没在黄色海洋里
- 警告太少：团队不知道哪些写法已经过时
- 标准不统一：有人用 CMake 3.10，有人用 3.20，警告行为完全不一样
我个人习惯的做法是：在 Presets 里统一控制这些开关，让所有开发者看到同样的警告级别。这样既不会漏掉重要信息，也不会被噪音干扰。
关键变量一览
CMake 提供了几个核心变量来控制警告和错误行为。我把它们整理成了表格，方便你对照查看：
| 变量名 | 作用 | 默认值 | 我常用的值 |
|---|---|---|---|
CMAKE_WARN_DEPRECATED |
是否显示已弃用特性的警告 | ON |
ON（开发阶段） |
CMAKE_ERROR_DEPRECATED |
是否将弃用警告视为错误 | OFF |
OFF（除非做迁移） |
CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION |
安装路径使用绝对路径时是否警告 | ON |
ON |
CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION |
安装路径使用绝对路径时是否报错 | OFF |
ON（生产构建） |
CMAKE_SUPPRESS_DEVELOPER_WARNINGS |
是否抑制开发者警告（如未使用的变量） | OFF |
OFF（开发）/ ON（发布） |
CMAKE_WARN_DEPRECATED 默认是开启的。如果你发现 CMake 输出里一堆 deprecated 字样，别急着关掉——先看看能不能升级写法。我曾经花了一个下午把项目里所有 add_definitions 改成 add_compile_definitions，虽然累，但之后 CMake 升级再也没出过问题。
在 Presets 中配置警告控制
好了，理论说完了，咱们直接看代码。在 CMakePresets.json 里，你可以通过 cacheVariables 来设置这些变量：
{
"version": 6,
"configurePresets": [
{
"name": "dev",
"displayName": "开发模式",
"description": "开发阶段使用，显示所有警告",
"cacheVariables": {
"CMAKE_WARN_DEPRECATED": "ON",
"CMAKE_ERROR_DEPRECATED": "OFF",
"CMAKE_SUPPRESS_DEVELOPER_WARNINGS": "OFF",
"CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION": "OFF"
}
},
{
"name": "release",
"displayName": "发布模式",
"description": "发布构建，严格检查",
"cacheVariables": {
"CMAKE_WARN_DEPRECATED": "ON",
"CMAKE_ERROR_DEPRECATED": "ON",
"CMAKE_SUPPRESS_DEVELOPER_WARNINGS": "ON",
"CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION": "ON"
}
},
{
"name": "ci",
"displayName": "CI 模式",
"description": "持续集成，零容忍弃用",
"cacheVariables": {
"CMAKE_WARN_DEPRECATED": "ON",
"CMAKE_ERROR_DEPRECATED": "ON",
"CMAKE_SUPPRESS_DEVELOPER_WARNINGS": "OFF",
"CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION": "ON"
}
}
]
}你看，我分了三个场景：
- dev：开发时宽松一点，看到警告但不阻断
- release：发布时严格，弃用直接报错，绝对路径安装也报错
- ci：持续集成时最严格，连开发者警告都不放过
这样做的好处是——开发同学不会被频繁打断，但 CI 流水线会帮你把问题卡住。我曾经在 CI 里抓到过好几次因为用了 target_include_directories 的旧语法导致跨平台编译失败的问题，要是没有这些严格检查，代码合并后才发现就晚了。
知识体系图
下面这张图帮你理清整个警告控制的核心逻辑：
避坑指南
- 别在根 CMakeLists.txt 里硬编码：以前我直接在文件里写
set(CMAKE_WARN_DEPRECATED OFF)，结果 CI 和本地行为不一致，排查了半天。现在全部交给 Presets 管理。 - CMAKE_ERROR_DEPRECATED 慎用：如果你项目里用了第三方库，而第三方库还在用旧语法，这个开关一开，整个项目可能直接编译不过。我建议只在 CI 或 release 模式开启。
- CMAKE_SUPPRESS_DEVELOPER_WARNINGS 不是万能药：它只抑制 CMake 自身的开发者警告，不会影响编译器的警告。别指望用它来关掉
-Wall级别的警告。
进阶技巧：结合编译器警告
说到编译器警告，其实 CMake 也提供了很好的支持。你可以通过 target_compile_options 配合 Presets 来统一管理：
{
"configurePresets": [
{
"name": "strict",
"cacheVariables": {
"CMAKE_CXX_FLAGS": "-Wall -Wextra -Werror -Wpedantic"
}
}
]
}但要注意——CMAKE_CXX_FLAGS 是全局的，会影响所有目标。我个人更推荐在 CMakeLists.txt 里用 target_compile_options 按目标设置，Presets 只负责控制 CMake 层面的警告行为。这样职责更清晰。
好了，关于警告和错误控制，核心思路就是这些。记住一句话：用 Presets 统一策略，用变量精准控制，用场景区分严格度。这样你的团队就不会再被「为什么我本地没警告，CI 却报错」这种问题困扰了。