根本原因是cmake未找到编译器：vs用户需在x64 native tools命令提示符中运行，mingw用户须将mingw64\bin加入path并验证gcc --version，且必须显式指定生成器（如-g "mingw makefiles"）并清空构建目录重试。
cmake .. 报 CMAKE_C_COMPILER not set 怎么办
这是 Windows 上最常遇到的错误，根本原因不是你的 CMakeLists.txt 写错了，而是 CMake 根本没找到可用的编译器。
VS 用户：确保你是在 x64 Native Tools Command Prompt for VS 2022（或对应版本）里运行命令，普通 PowerShell 或 CMD 不会自动加载 MSVC 工具链。
MinGW 用户：必须把 mingw64\bin（例如 D:\mingw64\bin）加进系统 PATH，然后重启终端；验证方式是直接在终端输入 gcc --version 能正常输出版本号。
两种情况都建议显式指定生成器，避免 CMake 自动猜错：
- 用 MSVC：运行
cmake .. -G "Visual Studio 17 2022" -A x64 - 用 MinGW：运行
cmake .. -G "MinGW Makefiles"
生成器（Generator）选错会导致构建失败
Windows 下不同生成器对应完全不同的构建流程和输出产物，混用必报错。
Visual Studio 17 2022 生成的是 .sln 和 .vcxproj 文件，后续要用 cmake --build . --config Release 或直接双击打开 VS 构建。
MinGW Makefiles 生成的是 Makefile，后续必须用 mingw32-make（不是 make，Windows 上通常没有这个命令）执行编译。
常见陷阱：
- 误用
NMake Makefiles却没运行vcvarsall.bat配置环境 → 报cl is not recognized - 用
Visual Studio生成器却在普通 CMD 里跑cmake --build→ 找不到MSBuild.exe - 64 位项目用了
-A Win32却链接了 64 位库 → 链接时报LNK2001符号未定义
构建目录必须是空的或全新创建
CMake 的缓存机制很“固执”，一旦 CMakeCache.txt 存在，它会复用旧配置，哪怕你改了 CMakeLists.txt 或切换了编译器，也大概率继续报错。
安全做法永远是：
- 新建独立构建目录：
mkdir build && cd build - 首次运行：
cmake .. -G "...” - 如果要换生成器或编译器，不要删
CMakeCache.txt，直接删整个build目录重来
尤其在调试 Detectron2、OpenCASCADE 这类依赖 CUDA 或第三方库的项目时，残留缓存常导致 find_package 找到错误路径或版本。
第三方库路径没被正确识别
像 OpenCV、Open3D、TeraTerm 这类项目，CMake 需要定位头文件和 .lib/.a 文件。Windows 下最容易出问题的是路径分隔符和空格。
推荐写法（全部用正斜杠或双反斜杠）：
- 在
cmake-gui中设置OPENCV_DIR为D:/opencv/build（不是D:\opencv\build） - 命令行传参用双引号包裹含空格路径：
cmake .. -DOpenSSL_ROOT_DIR="C:/Program Files/OpenSSL-Win64" - 避免用中文路径或桌面路径（如
C:\Users\用户名\Desktop\...），CMake 解析可能失败
验证是否生效：生成后打开 CMakeCache.txt，搜索关键词（如 OpenSSL_INCLUDE_DIR），确认值是你期望的绝对路径。
真正麻烦的从来不是语法，而是 CMake 在背后默默读取的环境变量、PATH、缓存和生成器语义——这些细节不显眼，但改错一个就卡死一整天。
