cmake .. 报错“Could not create named generator”是因为未指定生成器且未在VS开发者命令提示符中运行，导致CMake无法自动识别构建系统；解决方法是显式使用-G参数指定生成器（如-G "Visual Studio 16 2019" -A x64）或确保在正确环境中执行。
cmake .. 命令为什么报错“Could not create named generator”
没指定生成器（generator）时，cmake .. 在 Windows 上默认找不到可选的构建系统，就会直接失败。这不是你 CMakeLists.txt 写错了，而是 cmake 不知道该生成 Visual Studio 项目、MinGW Makefile 还是 Ninja 文件。
解决办法是显式加 -G 参数：
- 用 MSVC（Visual Studio）：直接运行
cmake ..通常能自动识别——但前提是必须在「开发者命令提示符」或已加载vcvarsall.bat的终端里执行；否则会报错 - 用 MinGW：运行
cmake .. -G "MinGW Makefiles"，注意引号不能省，空格要严格匹配 - 用 Ninja（推荐提速）：先装好 ninja（
choco install ninja或手动下载），再运行cmake .. -G Ninja
常见坑：-G"MinGW Makefiles" 中间没空格、引号用中文符号、路径含空格未加引号，都会导致解析失败。
build 目录必须单独建，不能在源码根目录下直接 cmake
CMake 设计上禁止在源码目录（source directory）里原地构建（in-source build）。如果你直接在 CMakeLists.txt 所在目录执行 cmake .，它会把 CMakeCache.txt、CMakeFiles/ 等中间文件全塞进源码树，污染 Git、干扰 IDE 检索，后续 clean 极难彻底。
正确做法永远是：
- 新建独立目录：
mkdir build && cd build - 从 build 目录运行
cmake ..（注意是两个点，指向上级源码目录） - 编译产物和临时文件全部留在
build/内，删掉整个目录就干净了
VSCode 的 CMake Tools 插件默认也走这套流程，所以手动命令行时别图省事跳过这步。
mingw32-make 和 cmake --build . 的区别在哪
两者都能编译，但底层机制不同，影响错误定位和跨平台一致性：
-
mingw32-make是 MinGW 自带的 make 工具，只认Makefile，必须配合-G "MinGW Makefiles"生成的构建文件才能用 -
cmake --build .是 CMake 提供的统一接口，不管你是用 Ninja、MSVC 还是 MinGW 生成的构建文件，它都调用对应后端；比如 Ninja 项目就调ninja，MSVC 项目就调msbuild - 推荐统一用
cmake --build .，尤其当项目可能换生成器时，脚本不用改；加--config Release还能控制构建类型（MinGW 下无效，但写上不报错）
MinGW 用户容易忽略：如果装的是 64 位 MinGW-w64，默认命令可能是 mingw64-make 而非 mingw32-make，查不到命令时先 where mingw 确认实际可执行名。
编译完的 exe 找不到？检查 CMakeLists.txt 的 add_executable 名称
最终生成的可执行文件名，**完全由 add_executable() 第一个参数决定**，不是文件夹名、也不是 project() 名。
例如：
project(hello) add_executable(app main.cpp)
生成的就是 app.exe，不是 hello.exe。很多人 cd 到 build 目录后直接 ./hello.exe，自然报 “系统找不到指定的文件”。
验证方法：
- 编译完成后，看
build/CMakeFiles/下有没有app.dir/这样的子目录 - 或者直接
dir *.exe（Windows）或ls *.exe（Git Bash）列出所有 exe - 如果用了
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ...)，exe 可能被输出到别的路径，这时得去对应目录找
最稳妥的方式：编译完立刻 cmake --build . --target help 查看所有可构建目标，里面会明确列出 executable 名。
