cmake不是编译器或构建工具，而是构建系统生成器，负责生成makefile或visual studio工程等；真正执行编译的是make、ninja或msbuild，新手常见问题源于未遵守外部构建规范及路径理解错误。
直接说结论：CMake 不是编译器，也不是构建工具，它只负责生成构建系统（比如 Makefile 或 Visual Studio 工程），真正干活的是 make、ninja 或 MSBuild。新手最容易卡在“为什么 cmake .. 没报错但 make 找不到源文件”这类问题上——根源几乎全是路径和构建目录没分清。
cmake .. 为什么总在 build 目录里执行？
因为 CMake 强烈要求「外部构建」（out-of-source build）。cmake .. 中的 .. 是指向上一级找 CMakeLists.txt，而当前目录（即 build）必须为空或全新，否则旧缓存可能干扰配置。
-
mkdir build && cd build && cmake ..是唯一推荐的起手式，别图省事在源码根目录下直接cmake . - 如果误在源码目录执行过
cmake .，会生成一堆CMakeFiles/、CMakeCache.txt，必须手动删干净再进build目录重来 -
cmake -S . -B build是现代写法（CMake 3.13+），更明确指定源码目录（-S）和构建目录（-B），避免 cd 错误
add_executable() 找不到源文件的常见原因
不是语法错，而是路径解析规则被忽略：add_executable(myapp main.cpp) 中的 main.cpp 是相对 CMAKE_CURRENT_SOURCE_DIR 的路径，不是当前 shell 路径。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 假设项目结构是
src/main.cpp和根目录CMakeLists.txt，就得写add_executable(myapp src/main.cpp)，不能只写main.cpp - 多文件时别拼字符串，用变量管理：
set(SRCS src/main.cpp src/utils.cpp)，再add_executable(myapp ${SRCS}) - 头文件包含路径要显式加：
target_include_directories(myapp PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/include)，否则#include "xxx.h"会失败
CMAKE_CXX_STANDARD 设置后仍报 C++17 特性不支持
仅 set(CMAKE_CXX_STANDARD 17) 不够，它只影响编译器命令行的 -std= 参数，但某些旧编译器（如 GCC 4.8）根本不支持 C++17，而 CMake 默认不检查兼容性。
- 必须加
set(CMAKE_CXX_STANDARD_REQUIRED ON)，否则 CMake 会悄悄降级到 C++11 - 若用 Clang 或 MSVC，还需确认工具链是否启用对应标准，例如 MSVC 需 VS2017+ 才完整支持 C++17
- 检查实际编译命令：运行
make VERBOSE=1，看输出里是否有-std=c++17；没有就说明REQUIRED没生效或编译器太老
为什么 cmake --build build 总比 make 多一层封装？
cmake --build 是跨平台统一接口，底层调用的是你生成的构建系统，不是替代 make。它的价值在「不用记不同平台命令」——Linux 用 make，Windows 用 msbuild，Ninja 用 ninja，全被它屏蔽了。
-
cmake --build build等价于cd build && make（Linux）或cd build && msbuild MyApp.sln（Windows） - 想并行编译：用
cmake --build build --parallel 4，比make -j4更可靠，尤其在 Ninja 或 Xcode 后端下 - 若提示
Unknown argument --build，说明 CMake 版本 cd build && make
最常被跳过的细节是：CMakeLists.txt 改动后，必须重新运行 cmake ..（或 cmake -S . -B build）才能更新构建文件；只改源码不重配置，新增的 target_link_libraries() 或 find_package() 永远不会生效。
