cmake不导出编译命令，而是生成构建系统（如makefile/ninja）；真正可复用的“导出”是通过install(export)生成targets.cmake和config.cmake等文件，使其他项目能用find_package()消费目标配置。
cmake 本身不“导出编译命令”，它生成的是构建系统（比如 Makefile 或 Ninja 构建文件），真正执行编译的是 make、ninja 等工具。你真正想问的，通常是：如何让别人或 CI 环境复现你的构建过程？或者如何把构建逻辑“固化”下来供他人调用？ 答案不是导出命令行，而是导出构建配置和目标信息。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
怎么查看 CMake 实际执行的编译命令？
这不是导出，而是调试/观察：
- 构建时加 --verbose（Makefile 后端）：make --verbose 或 make VERBOSE=1
- Ninja 后端用：ninja -v
- 更彻底的方式是启用 CMake 日志：cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ..，会生成 compile_commands.json，这是很多编辑器（如 VSCode + C/C++ 插件、clangd）读取的权威编译参数来源
- 注意：compile_commands.json 只包含源文件到编译命令的映射，不含链接命令；它也不含 install 或自定义 add_custom_command 的逻辑
为什么不能直接“导出 make 命令字符串”？
CMake 不生成固定命令，因为：
- 编译命令依赖于构建后端（Make/Ninja/VS/Xcode），后端不同，命令格式不同
- 命令中大量路径是相对的、临时的（如 build/src/main.o），硬编码会失效
- 宏定义、包含路径、编译标志都由 CMake 计算得出，且可能随 CMAKE_BUILD_TYPE、平台、toolchain 变化
- 直接拼接 g++ -I... -D... -o ... 容易漏掉隐式依赖、响应文件（@response-file）、多阶段编译（如 MOC）等 CMake 内部机制
- 一旦项目加了 target_compile_features 或 check_cxx_source_compiles，手动还原几乎不可能
真正可复用的“导出”方式是什么？
导出的是可被其他 CMake 项目消费的结构化信息：
- install(TARGETS ... EXPORT mylibTargets) + install(EXPORT mylibTargets ...) → 生成 mylibTargets.cmake 和 mylibConfig.cmake
- 这些文件里包含目标属性（IMPORTED_LOCATION、INTERFACE_INCLUDE_DIRECTORIES 等），别人用 find_package(mylib) 就能拿到完整配置
- 如果只是想打包给非 CMake 用户（比如只给 .so + 头文件），那就用 cmake --install . --prefix /path/to/dist，然后把整个 /path/to/dist 目录分发出去
- 避免手动复制 .a/.so 和头文件——CMake 的 install(DIRECTORY ...) 和 install(FILES ...) 才保证路径和权限正确
容易被忽略的关键点
很多人卡在“导出”这一步，其实问题不在导出动作本身，而在：
- 忘记设置 CMAKE_INSTALL_PREFIX，导致 install 默认写到 /usr/local（需要 sudo）
- install(EXPORT ...) 没配 NAMESPACE，导致 find_package 找不到 target 名称
- 导出的 Config.cmake 文件没处理版本号（set_and_check(mylib_VERSION 1.2.3)），下游 find_package(mylib 1.3 REQUIRED) 直接失败
- 把 build/ 目录直接 tar 丢给别人——里面全是绝对路径和临时文件，完全不可移植
