CMake不是编译器,而是跨平台构建系统生成器;它通过解析CMakeLists.txt生成Makefile等构建文件,再经make或cmake --build执行编译,cmake ..仅配置不编译,必须后续调用构建命令才能生成可执行文件。

直接说结论:CMake 不是编译器,也不是构建工具本身,它只负责生成构建系统(比如 Makefile 或 Ninja 文件)。你写对 CMakeLists.txt,再执行 cmake 和 make(或 cmake --build),才能真正编译出可执行文件。
为什么 cmake .. 之后没有生成可执行文件
这是新手最常卡住的地方——误以为 cmake 就是“编译命令”。实际上:
-
cmake ..只做一件事:读取上级目录的CMakeLists.txt,检查编译器、路径、语法,生成构建系统文件(如Makefile),不编译任何代码; - 必须再运行
make(Linux/macOS)或cmake --build .(跨平台推荐)才算真正开始编译; - 如果
make报错,常见原因是add_executable中指定的源文件名写错了(比如写成main.cpp,但实际文件叫hello.cpp),或文件不在当前目录下。
add_executable 的参数顺序和路径陷阱
add_executable 看似简单,但路径处理极易出错。它第一个参数是目标名(生成的可执行文件名),第二个及之后是源文件路径——这些路径是相对于 CMakeLists.txt 所在目录的,不是相对于 build 目录。
组合式C++代码评审方案,融合静态分析、AI推理、多轮迭代评审和C++专项检查,适用于PR审查、增量代码审查、全项目评审和代码质量评分,触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 错误写法:
add_executable(app src/main.cpp),但CMakeLists.txt和main.cpp都在项目根目录,src/子目录根本不存在; - 正确写法:确保路径真实存在,且用相对路径;若源文件在子目录,就老老实实写
src/main.cpp; - 不要用绝对路径(如
/home/user/project/main.cpp),这会让项目无法共享或迁移到其他机器; - 支持通配符(如
add_executable(app *.cpp)),但不推荐——CMake 不保证遍历顺序,且 IDE 无法索引,调试时容易混乱。
cmake_minimum_required 版本选低还是选高
写 cmake_minimum_required(VERSION 3.10) 很常见,但它不是“越低越好”或“越高越好”,而是取决于你用的语法和函数。
- 3.10 支持
project(... LANGUAGES CXX),但不支持target_compile_features的细粒度控制; - 如果你用了
find_package(Qt6 REQUIRED),就得至少 3.15;用FetchContent_Declare下载外部依赖,则建议 3.14+; - 生产项目建议设为当前团队最低可用版本(比如 3.20),避免因旧版本缺失关键特性而临时降级语法;
- 设太高(如 3.30)可能导致 CI 环境里 CMake 太旧而失败,尤其某些 Linux 发行版仓库自带版本较老(Ubuntu 22.04 默认是 3.22)。
build 目录一定要单独建,不能和源码混在一起
把 build 目录建在项目根目录下(mkdir build && cd build),而不是直接在源码目录里运行 cmake .,这不是仪式感,是硬性工程规范。
-
cmake .是“in-source build”,会把所有中间文件(CMakeCache.txt、CMakeFiles/、对象文件)全塞进源码目录,Git 易误提交,IDE 显示混乱; -
cmake ..是“out-of-source build”,构建产物完全隔离,删掉整个build目录也不会影响源码; - 现代写法更推荐
cmake -S . -B build,显式声明源码目录(-S)和构建目录(-B),语义清晰,且兼容 Ninja、VS 等多生成器场景; - 一旦用了 out-of-source,就别再手动生成
Makefile或手动调用g++,否则依赖关系会断裂——CMake 管理的是整个构建图,不是单个命令。
最容易被忽略的一点:CMake 不会自动重读 CMakeLists.txt。改完配置后,必须重新运行 cmake ..(或 cmake -S . -B build),否则新设置不会生效——哪怕只是加了一行 set(CMAKE_CXX_STANDARD 17),也得重新配置,不是改完保存就 ok。

















