CMake命令必须在独立构建目录中执行，不可在源码根目录运行cmake .，否则会污染源码目录；最小可用CMakeLists.txt需包含cmake_minimum_required、project和add_executable三行；构建流程分两步：cmake生成构建文件，后端工具（如make）执行编译；install目标需手动触发，且默认前缀/usr/local需sudo权限。
cmake 命令必须在构建目录里执行
直接在源码根目录下运行 cmake . 看似省事，但会污染源码目录——生成 CMakeCache.txt、CMakeFiles/、Makefile 等中间文件，Git 提交时容易误提交，协作时也容易引发冲突。
正确做法是新建一个独立的构建目录：
mkdir build && cd build-
cmake ..（注意是两个点，指向源码目录） - 后续所有构建命令都在
build/目录下运行
这样源码目录干净，且可并行使用多个构建目录（比如 build-debug 和 build-release），互不干扰。
CMakeLists.txt 至少要写这三行
新手常卡在写不出能跑的 CMakeLists.txt。其实最小可用版本就三行，缺一不可：
-
cmake_minimum_required(VERSION 3.10)：指定最低 CMake 版本，低于该版本会报错退出 -
project(myapp)：声明项目名，同时隐式定义变量PROJECT_NAME和PROJECT_VERSION -
add_executable(myapp main.cpp)：告诉 CMake 编译哪个可执行文件、用哪些源文件
注意：add_executable 的第一个参数是输出的可执行文件名，不是源文件名；第二个及之后的参数才是源文件路径（支持多个，用空格分隔）。
make 不是 cmake 的子命令，而是独立工具
执行完 cmake .. 后，CMake 只是生成了构建系统（比如 Linux 下是 Makefile），真正编译靠的是 make（或 ninja、msbuild 等后端工具）。
常见误区：
- 误以为
cmake --build是“高级写法”——其实它只是封装，底层仍调用make或对应构建器 - 在 Windows 上用 Visual Studio 生成器时，
cmake --build .实际调用的是msbuild，不是make - 想看编译命令细节？加
make VERBOSE=1，而不是cmake VERBOSE=1
所以构建流程本质是两步分离的：CMake 负责“生成规则”，后端构建工具负责“执行规则”。
install 目标默认不生效，得手动触发
即使你在 CMakeLists.txt 里写了 install(TARGETS myapp DESTINATION bin)，运行 make 也不会把可执行文件复制到 /usr/local/bin（或你设的 CMAKE_INSTALL_PREFIX）。
必须显式执行安装步骤：
-
make install（对应 Makefile 后端） -
cmake --build . --target install（更通用，跨后端一致）
默认安装前缀是 /usr/local，Linux 下写入需要 sudo 权限；开发调试时建议用本地路径，比如：
cmake -DCMAKE_INSTALL_PREFIX=$HOME/myapp-install ..
否则 make install 会静默失败或权限拒绝，新手常以为 install() 指令没起作用。
最易被忽略的点：CMake 不会自动帮你清理旧构建产物。改了 CMakeLists.txt 后，如果只是重新 cmake ..，旧的缓存可能让改动不生效；稳妥做法是删掉整个 build/ 目录再重来。
