Windows上用CMake编译C/C++项目核心是让CMake找到MinGW或MSVC编译器并生成可用构建文件：需显式指定-G参数（如"MinGW Makefiles"）或使用对应工具链命令行，且CMakeLists.txt必须声明语言和C++标准，build目录须独立于源码树。
Windows 上用 CMake 编译 C/C++ 项目，核心就两件事：让 cmake 找到编译器，再让它生成能跑起来的构建文件。其他所有“卡住”，基本都绕不开这两点。
怎么让 cmake 找到 MinGW 或 MSVC 编译器
cmake 不会自动猜你装了什么编译器，尤其在 Windows 上，默认连 gcc 都不认——除非你明确告诉它用哪个工具链。
- 用 MinGW-w64（推荐轻量场景）：必须加
-G "MinGW Makefiles"参数，否则 cmake 默认尝试生成 Visual Studio 工程，报错CMAKE_C_COMPILER not set或直接失败 - 用 MSVC（如 VS 2019/2022）：不加
-G也能工作，但前提是打开的是对应版本的x64 Native Tools Command Prompt，普通 CMD/PowerShell 里cl.exe不在 PATH 中，cmake 就找不到 - 验证编译器是否真可用：在终端里单独运行
gcc --version或cl，成功返回版本号才算到位；只配了 PATH 却没重启终端，常导致 cmake 看不见编译器
CMakeLists.txt 最小可用写法别漏关键项
新手常把 CMakeLists.txt 写成“能过 cmake 配置”，但一编译就报 unknown language "CXX" 或链接失败，问题多出在语言声明和标准指定上。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 哪怕只编译 C 文件，也要显式写
project(MyProj C)，不能只写project(MyProj)—— 否则 cmake 默认启用 C++ 支持，却找不到g++或cl的 C++ 模式 - 如果用了 C++17 特性，必须加
set(CMAKE_CXX_STANDARD 17)，且确保编译器实际支持（MinGW-w64 8.1+、MSVC 2017+） -
add_executable()的源文件路径要写对：比如src/main.cpp就得保证文件真实存在，相对路径以CMakeLists.txt所在目录为基准，不是 build 目录
build 目录必须干净且独立于源码
在源码根目录下直接 cmake . 是最常见错误操作，会导致生成文件污染源码树，后续切换编译器或清理失败。
- 务必新建空
build目录（如mkdir build && cd build），然后从该目录运行cmake .. -G "MinGW Makefiles" - 如果之前用 VS 生成器试过，又想切回 MinGW，必须删掉整个
build目录重来——cmake 不允许混用不同生成器 - 执行
cmake --build .前，确认当前在build目录下；若在源码目录下误输，会报Cannot determine what kind of build system was used
make 或 cmake --build 失败时先看这三行输出
编译阶段出错，不要急着搜错误关键词，先盯住 cmake 运行末尾的几行关键提示：
- 看到
-- Build files have been written to: ...→ 配置成功，问题出在构建阶段 - 看到
-- Configuring done但没后续 → cmake 卡在某个find_package()或条件判断里，检查是否漏装依赖（如 OpenCV 编译时缺 zlib） - 看到
CMake Error at CMakeLists.txt:xx→ 错误在配置阶段，通常是语法错或变量未定义，不是编译器问题
真正容易被忽略的是：cmake 生成的 Makefile 或 .sln 文件本身没问题，但 make 调用 gcc 时因环境变量缺失（如 PATH 里没有 mingw64/bin）而失败——此时错误信息里往往只有 sh: gcc: command not found，而非清晰的编译错误。
