必须用out-of-source构建，因为直接在源码目录运行cmake .会污染源码树，导致Git混乱、多配置冲突、清理困难；正确做法是mkdir build && cd build && cmake ..，实现源码与构建产物彻底隔离。
cmake --version 能跑通，只是说明安装成功；真正要开始用，第一步不是写 CMakeLists.txt，而是**选对构建目录**。
为什么必须用 out-of-source 构建？
直接在源码目录下运行 cmake . 看似省事，但会把 CMakeCache.txt、CMakeFiles/、Makefile 全塞进源码树里。后果很实际：
– git status 一堆未跟踪文件，每次都要手动 git clean -fd
– 想换编译器或加 -DCMAKE_BUILD_TYPE=Debug，得先 make clean 再删缓存，容易漏
– 多个构建配置（如 Debug / Release / ASan）无法并存
正确的初始化方式：mkdir build && cd build && cmake ..
这是现代 CMake 的默认实践，也是几乎所有官方教程和开源项目采用的方式。
– build 目录名可任意，比如 build-debug、build-release
– cmake .. 中的 .. 表示上层是源码根目录，CMake 会自动找到 CMakeLists.txt
– 如果源码根目录没有 CMakeLists.txt，会报错：CMake Error: The source directory ".../build" does not appear to contain CMakeLists.txt
第一次运行 cmake 时最常卡在哪？
不是语法错误，而是找不到编译器或基础工具链：
– Linux 上没装 build-essential（缺 gcc、g++、make），会提示：CMake Error: No CMAKE_C_COMPILER could be found
– Windows 上没装 Visual Studio 或没勾选「Desktop development with C++」，或者 MinGW 没加进 PATH，也会触发类似错误
– macOS 上没装 Xcode Command Line Tools，运行 xcode-select --install 才能解决
– 不要试图靠 set(CMAKE_C_COMPILER ...) 硬指定来绕过——先配好环境，比改配置更可靠
确认 cmake 配置成功的最小信号是什么？
不是看到 “Build files have been written to…”，而是：
– 当前构建目录下出现 CMakeCache.txt 和 CMakeFiles/ 子目录
– 运行 ls -A 能看到这些文件，且没有报错输出
– 此时才该执行 cmake --build . 或 make（取决于生成器）
– 如果后续编译失败，问题大概率出在 CMakeLists.txt 逻辑或源码本身，而不是构建流程启动阶段
cmake . 是标准姿势——这些细节不踩一遍坑，很难理解为什么别人推荐 build/ 目录必须隔离。 
