简介CMake 3.10.0 Windows 64位安装包是一款面向Windows开发者的跨平台构建工具发行版。它借助CMakeLists.txt脚本来描述项目结构能自动生成Visual Studio解决方案、Makefile、Ninja等目标文件帮助开发者在不同编译环境下统一管理C/C工程尤其适合涉及多模块、多依赖或需要对接MSVC的Windows项目。该rar压缩包大小约18.61MB下载页未单独列出内部文件数量与类型解压后即可运行安装程序并同时获得命令行工具 cmake 与图形界面 cmake-gui。已有1675人学习/下载此版本相对后续版本3.10.0在稳定性与兼容性上较为均衡适合需要固定构建环境、期望避免最新版行为变化影响现有流程的开发者。作为基础构建组件它既能降低项目配置门槛也为后续接入CTest、CPack等工具保留了扩展空间。 干过 Windows 下 C/C 开发的人应该都翻过 CMake 这堵墙。前阵子刚帮一个同事收拾老项目对方塞过来一个cmake-3.10.0-win64-x64.rar说“解压了不知道下一步干嘛”。我看到这个包的时候第一反应是在这个动辄 CMake 3.20 的年代怎么还有人拿 3.10 出来。但转念一想很多存量工程用的就是老版本稳定、习惯、构建脚本都是按老语法写的新版本未必直接兼容。所以这篇东西不是教你去追新版本而是就着这个 rar 包本身把安装、环境配置、以及最常被问的几个坑——相对路径、输出目录带 Debug、预编译头、toolchain 指定——一次说透。这个包能干什么简单说CMake 是一个跨平台的构建系统生成器它不直接编译代码而是根据 CMakeLists.txt 生成你想要的工程文件比如 Visual Studio 的.sln、MinGW 的 Makefile或者 Ninja。3.10.0 这个版本虽然是 2017 年底的东西但它的核心功能已经覆盖了绝大部分日常场景target_link_libraries、add_executable、install、ExternalProject这些都齐了生成 VS2017 及更低版本的工程完全没有问题。适合还在维护老项目、或者被公司网络限制没法下载新版 CMake 的朋友参考也适合刚入门想知道“解压 rar 后怎么办”的新手。1. 先别急着双击搞清楚这个 RAR 包的底细1.1 为什么 3.10.0 这个版本还有人用版本号往往比你想的更代表“稳定边界”。CMake 3.10.0 是 3.10 系的第一个发行版它支持target_sources、add_compile_definitions这些后来被大量使用的命令也支持-A平台参数来指定 VS 生成器的架构。对于许多公司内部的老 C 工程CMakeLists.txt 大概率是几年前写成型的语法上没有用到新特性那么 3.10 和 3.27 在“生成 VS 工程”这个动作上结果差别并不大。但要注意老版本在识别新版本 Visual Studio 上会吃亏。cmake-3.10.0默认只能识别到 VS2017如果你机器上只装了 VS2022那用默认 generator 会直接报错。这也解释了为什么很多人下载老版本后第一句就是在命令行里敲cmake --version然后开始怀疑人生。后面我会给出替代方案。1.2 解压之后该检查什么拿到cmake-3.10.0-win64-x64.rar别急着双击cmake-gui.exe。先看一下目录结构这是所有 CMake Windows 分发包的标准布局cmake-3.10.0-win64-x64/ bin/ cmake.exe cmake-gui.exe cpack.exe ctest.exe share/ cmake-3.10/ Modules/ Templates/ doc/ licenses/重点确认bin目录下有cmake.exeshare\cmake-3.10\Modules里有FindPackage.cmake等标准模块。很多时候“装好了但 find_package 失败”就是因为Modules目录缺失或者路径被移动。这个包是 64 位版本只能跑在 64 位 Windows 上但生成的编译目标架构由你传给 CMake 的参数决定并不要求你的目标平台必须是 64 位。另外建议校验一下文件 SHA-256。CMake 官方在 download 页面会给出每个安装包的 checksum。虽然这个 rar 可能是第三方转存但花半分钟验一下能避免用到被篡改的二进制。Windows 下用 PowerShellGet-FileHash .\cmake-3.10.0-win64-x64.rar -Algorithm SHA256然后和官方值对照。这一步我一般都会做尤其是从非官网渠道下的压缩包。2. 安装与环境变量配置手动 PATH 才是正路2.1 不要用“解压即用”骗自己这个问题十个新手九个踩。CMake 的压缩包解压后虽然可以直接运行bin\cmake.exe但你在命令行里敲cmake时Windows 并不会自动去bin目录里找。所谓“解压即用”指的是不需要执行安装程序但不等于不需要配置环境变量。你必须把D:\dev\cmake-3.10.0-win64-x64\bin这种路径加进系统 PATH才能全局使用。更稳妥的做法是在用户环境变量里追加而不是改系统 PATH省得把系统搞乱。打开“编辑环境变量”对话框在Path变量中新增一行D:\dev\cmake-3.10.0-win64-x64\bin保存后重开一个命令行窗口让环境变量重新加载。然后验证cmake --version输出应该类似cmake version 3.10.0 CMake suite maintained and supported by Kitware (kitware.com/cmake).看到 3.10.0说明 PATH 生效。2.2 命令行里的第一条 CMake 命令配置环境后你会发现 CMake 最常用的其实不是 GUI而是命令行。GUI 适合临时看选项但真正的可复现构建得靠命令。建议先在你的项目根目录下建一个build子目录把生成文件全部隔离在 build 目录里不要让.sln、.vcxproj散落到源码目录中。这是老手的基本习惯也是后期用.gitignore省心的前提。一个最简单的流程mkdir build cd build cmake ..cmake ..会自动检测当前系统里可用的 generator。如果机器上装了多个版本的 VS这里会首选最新版。如果默认生成的不是你想要的架构比如你需要 Win32 而不是 x64可以显式指定cmake .. -A Win32-A这个参数从 3.10 开始就已经支持这也是 3.10.0 相对旧版本 2.8 的一大改进。指定 architecture 时不需要再费劲用-G Visual Studio 15 2017 Win64这种长字符串直接-A x64就行。但注意这个方式仅适用于 VS generator如果是 Ninja 或 Unix Makefiles不支持-A得靠 toolchain 文件去指定架构。3. 用 CMake 生成 VS 工程时最常被问的几个问题3.1 生成的 VS 工程如何用相对路径这是个高频词因为很多人发现用 CMake 生成.sln后vcxproj里的路径是绝对路径。比如AdditionalIncludeDirectoriesC:/Users/me/project/src/include;%(AdditionalIncludeDirectories)/AdditionalIncludeDirectories一旦把工程拷贝到别的路径或者换台机器路径全断。其实这锅不能全让 CMake 背CMake 默认生成的是相对路径工程只要你创建的 build 目录在项目目录内部它天然使用../形式引用源码。出现绝对路径的常见原因有三个你在 CMakeLists.txt 里显式用了绝对路径比如include_directories(${CMAKE_CURRENT_SOURCE_DIR}/...)但写错层级导致变量被展开成绝对路径。用file(GLOB ...)收集源文件时返回的是绝对路径虽然 CMake 在生成时会尝试转成相对路径但有些版本或特殊写法下还是可能把绝对路径带进工程文件。外部依赖的导入库目标IMPORTED_LOCATION里写死了路径。最干净的解决办法是在 CMakeLists.txt 里优先使用相对路径语义通过CMAKE_CURRENT_SOURCE_DIR和CMAKE_CURRENT_BINARY_DIR来引用路径而不是写死盘符。比如set(INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include) target_include_directories(myapp PRIVATE ${INCLUDE_DIR})这样 CMake 自身生成时会基于 build 目录自动计算相对位置。你可以在生成后打开.vcxproj检查一下正常会看到类似AdditionalIncludeDirectories..\..\include;%(AdditionalIncludeDirectories)/AdditionalIncludeDirectories这是预期的。如果始终出现绝对路径不妨手动清理 build 目录重新生成一次因为旧的 CMakeCache.txt 里可能缓存了之前写死的路径。3.2 输出路径想去掉 Debug/Release 目录VS 的默认输出目录是$(SolutionDir)$(Platform)\$(Configuration)\也就是build\x64\Debug这种。但很多时候我们希望所有配置的输出都集中在同一个目录比如build\bin下这样便于后续打包。CMake 里改这个关键是设置CMAKE_RUNTIME_OUTPUT_DIRECTORY。最直接的方式是在顶层的 CMakeLists.txt 里针对不同配置分别设置set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/bin) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/bin)这样一来所有 exe 和 dll 都会输出到build/bin不再出现build\Debug、build\Release、build\x64\Debug等分散目录。注意如果项目里还生成了静态库或动态库那需要设置CMAKE_LIBRARY_OUTPUT_DIRECTORY和CMAKE_ARCHIVE_OUTPUT_DIRECTORY。很多人只设置了 RUNTIME结果库文件还是按配置分目录打包时又得去各个子目录里捡漏。还有一个小技巧如果你希望“去掉 debug”指的是生成的 exe 文件名不要带d后缀比如myappd.exe。这个不是 CMake 的默认行为而是 MSVC 运行库生成的默认规则。CMake 并不会自动给 debug 版加d除非你自己在代码里用_DEBUG宏去调整输出名。所以如果你发现 debug 版带d后缀其实是 VS 属性里的TargetName默认值改了或者你在 CMake 里写了类似set_target_properties(myapp PROPERTIES DEBUG_OUTPUT_NAME myapp)如果你想完全去掉配置目录还可以用VS_DEBUGGER_WORKING_DIRECTORY来控制调试器的工作目录但那是另一个话题了。3.3 指定预编译头文件与 toolchain 的坑热词里还有cmake 指定 precompiledheaderfile这其实是 VS 工程属性里的PrecompiledHeaderFile。CMake 3.10 里并没有一个target_precompile_headers命令那个命令要到 CMake 3.16 才引入。所以在 3.10 里你只能用老办法通过target_compile_options给 MSVC 加/Yu、/Fp参数或者手动修改生成后的.vcxproj。这非常啰嗦。一个常见的替代方案是使用set_target_properties配合VS_GLOBAL_*属性但 3.10 支持的 VS 全局属性有限。更靠谱的是用generator expression或直接设置源文件的属性。比如你在项目里已经有一个pch.h和pch.cpp你希望整个 target 预编译pch.h可以在 CMakeLists 里这样写set_source_files_properties(pch.cpp PROPERTIES COMPILE_FLAGS /Ycpch.h) set_source_files_properties(other.cpp PROPERTIES COMPILE_FLAGS /Yupch.h)这种写法很丑而且每个源文件都加一行不现实。所以我的建议是如果你在 3.10 上做大型项目最好升级到 3.16用target_precompile_headers一行搞定。如果无法升级就老实维护一个pch.cpp并把它的编译选项设置为/Yc其余的源文件通过目录属性添加/Yu。实测下来用 CMake 生成工程后VS 的预编译头配置确实能识别但修改过多时容易触发“预编译头未找到”的坑每次改完 CMakeLists 要全量 rebuild这是正常现象。至于cmake toolchain这是跨平台编译的核心。在 Windows 上如果你想用 Clang 或 MinGW 而不是 MSVC就需要写一个 toolchain 文件通过-DCMAKE_TOOLCHAIN_FILE指定。用 3.10 时toolchain 文件里常见的写法包括set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_C_COMPILER clang) set(CMAKE_CXX_COMPILER clang) set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -fms-compatibility)类似这样。要注意的是CMake 3.10 对 Clang 在 Windows 上的支持还不如现在成熟如果报一些莫名其妙的链接错误可以先试试用-G Visual Studio 15 2017配合 MSVC 生成排除 toolchain 本身的问题。4. 再聊聊执行 bash 命令和预编译的另类思路4.1 在 CMake 中执行 bash 命令的正确姿势热词里有cmake执行bash命令很多从 Linux 迁过来的同学喜欢在 CMake 里调bash -c ...来做一些预处理。CMake 本身提供了execute_process它可以在配置阶段执行任意命令。比如你想在 CMake 配置时获取当前 git 短哈希execute_process( COMMAND bash -c git rev-parse --short HEAD WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} OUTPUT_VARIABLE GIT_HASH OUTPUT_STRIP_TRAILING_WHITESPACE )这样GIT_HASH就会变成一串短哈希。但这里有几个必须注意的地方bash必须在你当前系统的 PATH 中。Windows 上通常来自 Git Bash 或 WSL。如果你的目标是调用 WSL 里的工具用wsl bash -c ...更靠谱。如果命令执行失败execute_process默认并不报错只是把返回码存在RESULT_VARIABLE中。你需要在后面手动判断execute_process(COMMAND bash -c false RESULT_VARIABLE ret) if(NOT ret EQUAL 0) message(FATAL_ERROR bash command failed: ${ret}) endif()不要把execute_process和自定义命令混为一谈。execute_process是在 CMake 配置阶段执行的也就是你敲cmake ..的时候执行而add_custom_command是在构建阶段执行的也就是你按 F5 编译的时候执行。如果你想要“每次编译前自动跑 bash”应该用add_custom_command(TARGET xxx PRE_BUILD COMMAND bash -c ...)而不是execute_process。4.2 预编译的写法本质是在缓存编译产物回到预编译头很多新手以为“预编译”是 CMake 的功能其实完全是编译器的功能。CMake 只是负责把对应的命令行参数传给编译器。MSVC 的/Yc表示创建预编译头/Yu表示使用预编译头。CMake 3.10 不支持高层的封装你只能用最原始的方式拼参数。在实际项目中如果一定要在 3.10 上把预编译头跑通我有一个折中方案写一个独立的cmake/precompiled.cmake脚本集中维护所有预编译头相关定义然后用include()引入。脚本里可以这样写macro(enable_pch_header target pch_header pch_source) set_source_files_properties(${pch_source} PROPERTIES COMPILE_FLAGS /Yc${pch_header}) target_sources(${target} PRIVATE ${pch_source}) target_compile_options(${target} PRIVATE /Yu${pch_header} /Fp${CMAKE_CURRENT_BINARY_DIR}/${target}.pch) endmacro()用这个宏之后至少不用在每个源文件里重复写/Yu。注意这里的/Fp要统一指向同一个.pch文件否则编译时找不到。而更现代的做法还是升级 CMake 后用target_precompile_headers。看到这里你应该已经明白很多“CMake 怎么做 X”的问题答案往往不是“CMake 提供了 Y”而是“这取决于你的编译器CMake 只是传话人”。5. 常见问题与排查技巧实录5.1 无法找到 cmake.exe 或“不是内部或外部命令”这类问题九成是 PATH 没配好。但还有一种隐蔽情况你确实加了 PATH但 CMake 的版本冲突。系统里装了 Python 自带的 CMake或者 Anaconda 里的 CMake它们的路径排在前面。命令行里敲cmake --version显示的可能是别的版本。这时候用where cmakeWindows 自带查看实际调用的路径。where cmake输出会列出所有出现在 PATH 里的 cmake.exe第一个就是当前生效的。如果发现不是你要的 3.10.0要么调整 PATH 顺序要么直接把D:\dev\cmake-3.10.0-win64-x64\bin挪到最前面。另一个原因是终端没有重启环境变量不会自动刷新。还有如果是用 PowerShell某些编辑器不会读取最新的用户环境变量需要重启编辑器或操作系统一次。5.2 CMake 生成 VS 工程时选错 generator3.10.0 默认支持的 VS 版本最高是 Visual Studio 15 2017。如果你装了 VS2022直接运行cmake ..时会报CMake Error at CMakeLists.txt:... (project): No CMAKE_C_COMPILER could be found.或者Could not find a matching installation of Visual Studio.这是因为 3.10 不认识 VS2022 的实例。解决思路有三个一是用-G Visual Studio 15 2017强制指定老版本 generator但前提是你机器上确实装了 VS2017二是用 Ninja 生成器绕过 VS 版本检测但需要单独装 Ninja三是老老实实下载新版 CMake。如果你今天刚拿到cmake-3.10.0-win64-x64.rar而电脑上只有 VS2022我的建议是放弃 3.10换用 3.20 以上的版本否则一路都是坑。但如果你想维护老工程又只有新 VS只能采用第二种方案装 Ninja 然后用cmake -G Ninja ..对这个场景而言Ninja 的配置更简单。5.3 路径带空格或者中文引发的问题CMake 对路径中的空格支持得不错但前提是路径里的空格都放在引号中。最常见的错误是在execute_process或add_custom_command里拼接路径时少了引号比如execute_process(COMMAND mytool.exe ${INPUT_PATH})如果INPUT_PATH是C:\Program Files\xx\input.txt那就会把Program和Files\xx\input.txt当成两个参数。老手会写成execute_process(COMMAND mytool.exe ${INPUT_PATH})但 CMake 会保留引号吗这取决于当前平台。在 Windows 上CMake 通常会自动为带空格的参数加引号但用bash -c时就会出问题因为 bash 的引号解析和 Windows 命令行不同。另一个情况是中文路径。CMake 3.10.0 对中文路径的支持不是很好尤其是当路径里有中文且代码文件用了非 UTF-8 编码时很容易报 “Invalid character”。建议开发环境的所有路径都使用纯英文加数字这是一个低成本但极其有效的避坑技巧。还有一点构建目录本身最好不要放在需要管理员权限的路径下比如C:\Program Files。不然每次 build 都可能遇到权限问题非常烦人。这个和 CMake 无关但和 Windows 下开发体验强相关。最后的一点个人体会玩 CMake 这么些年我越来越觉得版本和工具只是表面核心还是理解“生成”和“构建”的分离。cmake-3.10.0-win64-x64.rar这个老包如果你只是想快速生成一个 VS 工程它绝对够用但如果你想玩预编译头、toolchain、跨版本 VS那真的建议顺手去官网下个 3.20几兆的东西省下的是大把调试时间。要是遇上不能上外网的环境那就在内网搭个本地共享目录把这几个版本都放进去随用随取。最后再分享一个小技巧拿到任何 CMake 安装包后第一时间用cmake --version确认路径生效用cmake --help确认可用的 generator。这两条命令会帮你省掉一半的“运行不了”的困惑。本文还有配套的精品资源点击获取
简介CMake 3.10.0 Windows 64位安装包是一款面向Windows开发者的跨平台构建工具发行版。它借助CMakeLists.txt脚本来描述项目结构能自动生成Visual Studio解决方案、Makefile、Ninja等目标文件帮助开发者在不同编译环境下统一管理C/C工程尤其适合涉及多模块、多依赖或需要对接MSVC的Windows项目。该rar压缩包大小约18.61MB下载页未单独列出内部文件数量与类型解压后即可运行安装程序并同时获得命令行工具 cmake 与图形界面 cmake-gui。已有1675人学习/下载此版本相对后续版本3.10.0在稳定性与兼容性上较为均衡适合需要固定构建环境、期望避免最新版行为变化影响现有流程的开发者。作为基础构建组件它既能降低项目配置门槛也为后续接入CTest、CPack等工具保留了扩展空间。 干过 Windows 下 C/C 开发的人应该都翻过 CMake 这堵墙。前阵子刚帮一个同事收拾老项目对方塞过来一个cmake-3.10.0-win64-x64.rar说“解压了不知道下一步干嘛”。我看到这个包的时候第一反应是在这个动辄 CMake 3.20 的年代怎么还有人拿 3.10 出来。但转念一想很多存量工程用的就是老版本稳定、习惯、构建脚本都是按老语法写的新版本未必直接兼容。所以这篇东西不是教你去追新版本而是就着这个 rar 包本身把安装、环境配置、以及最常被问的几个坑——相对路径、输出目录带 Debug、预编译头、toolchain 指定——一次说透。这个包能干什么简单说CMake 是一个跨平台的构建系统生成器它不直接编译代码而是根据 CMakeLists.txt 生成你想要的工程文件比如 Visual Studio 的.sln、MinGW 的 Makefile或者 Ninja。3.10.0 这个版本虽然是 2017 年底的东西但它的核心功能已经覆盖了绝大部分日常场景target_link_libraries、add_executable、install、ExternalProject这些都齐了生成 VS2017 及更低版本的工程完全没有问题。适合还在维护老项目、或者被公司网络限制没法下载新版 CMake 的朋友参考也适合刚入门想知道“解压 rar 后怎么办”的新手。1. 先别急着双击搞清楚这个 RAR 包的底细1.1 为什么 3.10.0 这个版本还有人用版本号往往比你想的更代表“稳定边界”。CMake 3.10.0 是 3.10 系的第一个发行版它支持target_sources、add_compile_definitions这些后来被大量使用的命令也支持-A平台参数来指定 VS 生成器的架构。对于许多公司内部的老 C 工程CMakeLists.txt 大概率是几年前写成型的语法上没有用到新特性那么 3.10 和 3.27 在“生成 VS 工程”这个动作上结果差别并不大。但要注意老版本在识别新版本 Visual Studio 上会吃亏。cmake-3.10.0默认只能识别到 VS2017如果你机器上只装了 VS2022那用默认 generator 会直接报错。这也解释了为什么很多人下载老版本后第一句就是在命令行里敲cmake --version然后开始怀疑人生。后面我会给出替代方案。1.2 解压之后该检查什么拿到cmake-3.10.0-win64-x64.rar别急着双击cmake-gui.exe。先看一下目录结构这是所有 CMake Windows 分发包的标准布局cmake-3.10.0-win64-x64/ bin/ cmake.exe cmake-gui.exe cpack.exe ctest.exe share/ cmake-3.10/ Modules/ Templates/ doc/ licenses/重点确认bin目录下有cmake.exeshare\cmake-3.10\Modules里有FindPackage.cmake等标准模块。很多时候“装好了但 find_package 失败”就是因为Modules目录缺失或者路径被移动。这个包是 64 位版本只能跑在 64 位 Windows 上但生成的编译目标架构由你传给 CMake 的参数决定并不要求你的目标平台必须是 64 位。另外建议校验一下文件 SHA-256。CMake 官方在 download 页面会给出每个安装包的 checksum。虽然这个 rar 可能是第三方转存但花半分钟验一下能避免用到被篡改的二进制。Windows 下用 PowerShellGet-FileHash .\cmake-3.10.0-win64-x64.rar -Algorithm SHA256然后和官方值对照。这一步我一般都会做尤其是从非官网渠道下的压缩包。2. 安装与环境变量配置手动 PATH 才是正路2.1 不要用“解压即用”骗自己这个问题十个新手九个踩。CMake 的压缩包解压后虽然可以直接运行bin\cmake.exe但你在命令行里敲cmake时Windows 并不会自动去bin目录里找。所谓“解压即用”指的是不需要执行安装程序但不等于不需要配置环境变量。你必须把D:\dev\cmake-3.10.0-win64-x64\bin这种路径加进系统 PATH才能全局使用。更稳妥的做法是在用户环境变量里追加而不是改系统 PATH省得把系统搞乱。打开“编辑环境变量”对话框在Path变量中新增一行D:\dev\cmake-3.10.0-win64-x64\bin保存后重开一个命令行窗口让环境变量重新加载。然后验证cmake --version输出应该类似cmake version 3.10.0 CMake suite maintained and supported by Kitware (kitware.com/cmake).看到 3.10.0说明 PATH 生效。2.2 命令行里的第一条 CMake 命令配置环境后你会发现 CMake 最常用的其实不是 GUI而是命令行。GUI 适合临时看选项但真正的可复现构建得靠命令。建议先在你的项目根目录下建一个build子目录把生成文件全部隔离在 build 目录里不要让.sln、.vcxproj散落到源码目录中。这是老手的基本习惯也是后期用.gitignore省心的前提。一个最简单的流程mkdir build cd build cmake ..cmake ..会自动检测当前系统里可用的 generator。如果机器上装了多个版本的 VS这里会首选最新版。如果默认生成的不是你想要的架构比如你需要 Win32 而不是 x64可以显式指定cmake .. -A Win32-A这个参数从 3.10 开始就已经支持这也是 3.10.0 相对旧版本 2.8 的一大改进。指定 architecture 时不需要再费劲用-G Visual Studio 15 2017 Win64这种长字符串直接-A x64就行。但注意这个方式仅适用于 VS generator如果是 Ninja 或 Unix Makefiles不支持-A得靠 toolchain 文件去指定架构。3. 用 CMake 生成 VS 工程时最常被问的几个问题3.1 生成的 VS 工程如何用相对路径这是个高频词因为很多人发现用 CMake 生成.sln后vcxproj里的路径是绝对路径。比如AdditionalIncludeDirectoriesC:/Users/me/project/src/include;%(AdditionalIncludeDirectories)/AdditionalIncludeDirectories一旦把工程拷贝到别的路径或者换台机器路径全断。其实这锅不能全让 CMake 背CMake 默认生成的是相对路径工程只要你创建的 build 目录在项目目录内部它天然使用../形式引用源码。出现绝对路径的常见原因有三个你在 CMakeLists.txt 里显式用了绝对路径比如include_directories(${CMAKE_CURRENT_SOURCE_DIR}/...)但写错层级导致变量被展开成绝对路径。用file(GLOB ...)收集源文件时返回的是绝对路径虽然 CMake 在生成时会尝试转成相对路径但有些版本或特殊写法下还是可能把绝对路径带进工程文件。外部依赖的导入库目标IMPORTED_LOCATION里写死了路径。最干净的解决办法是在 CMakeLists.txt 里优先使用相对路径语义通过CMAKE_CURRENT_SOURCE_DIR和CMAKE_CURRENT_BINARY_DIR来引用路径而不是写死盘符。比如set(INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include) target_include_directories(myapp PRIVATE ${INCLUDE_DIR})这样 CMake 自身生成时会基于 build 目录自动计算相对位置。你可以在生成后打开.vcxproj检查一下正常会看到类似AdditionalIncludeDirectories..\..\include;%(AdditionalIncludeDirectories)/AdditionalIncludeDirectories这是预期的。如果始终出现绝对路径不妨手动清理 build 目录重新生成一次因为旧的 CMakeCache.txt 里可能缓存了之前写死的路径。3.2 输出路径想去掉 Debug/Release 目录VS 的默认输出目录是$(SolutionDir)$(Platform)\$(Configuration)\也就是build\x64\Debug这种。但很多时候我们希望所有配置的输出都集中在同一个目录比如build\bin下这样便于后续打包。CMake 里改这个关键是设置CMAKE_RUNTIME_OUTPUT_DIRECTORY。最直接的方式是在顶层的 CMakeLists.txt 里针对不同配置分别设置set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/bin) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/bin)这样一来所有 exe 和 dll 都会输出到build/bin不再出现build\Debug、build\Release、build\x64\Debug等分散目录。注意如果项目里还生成了静态库或动态库那需要设置CMAKE_LIBRARY_OUTPUT_DIRECTORY和CMAKE_ARCHIVE_OUTPUT_DIRECTORY。很多人只设置了 RUNTIME结果库文件还是按配置分目录打包时又得去各个子目录里捡漏。还有一个小技巧如果你希望“去掉 debug”指的是生成的 exe 文件名不要带d后缀比如myappd.exe。这个不是 CMake 的默认行为而是 MSVC 运行库生成的默认规则。CMake 并不会自动给 debug 版加d除非你自己在代码里用_DEBUG宏去调整输出名。所以如果你发现 debug 版带d后缀其实是 VS 属性里的TargetName默认值改了或者你在 CMake 里写了类似set_target_properties(myapp PROPERTIES DEBUG_OUTPUT_NAME myapp)如果你想完全去掉配置目录还可以用VS_DEBUGGER_WORKING_DIRECTORY来控制调试器的工作目录但那是另一个话题了。3.3 指定预编译头文件与 toolchain 的坑热词里还有cmake 指定 precompiledheaderfile这其实是 VS 工程属性里的PrecompiledHeaderFile。CMake 3.10 里并没有一个target_precompile_headers命令那个命令要到 CMake 3.16 才引入。所以在 3.10 里你只能用老办法通过target_compile_options给 MSVC 加/Yu、/Fp参数或者手动修改生成后的.vcxproj。这非常啰嗦。一个常见的替代方案是使用set_target_properties配合VS_GLOBAL_*属性但 3.10 支持的 VS 全局属性有限。更靠谱的是用generator expression或直接设置源文件的属性。比如你在项目里已经有一个pch.h和pch.cpp你希望整个 target 预编译pch.h可以在 CMakeLists 里这样写set_source_files_properties(pch.cpp PROPERTIES COMPILE_FLAGS /Ycpch.h) set_source_files_properties(other.cpp PROPERTIES COMPILE_FLAGS /Yupch.h)这种写法很丑而且每个源文件都加一行不现实。所以我的建议是如果你在 3.10 上做大型项目最好升级到 3.16用target_precompile_headers一行搞定。如果无法升级就老实维护一个pch.cpp并把它的编译选项设置为/Yc其余的源文件通过目录属性添加/Yu。实测下来用 CMake 生成工程后VS 的预编译头配置确实能识别但修改过多时容易触发“预编译头未找到”的坑每次改完 CMakeLists 要全量 rebuild这是正常现象。至于cmake toolchain这是跨平台编译的核心。在 Windows 上如果你想用 Clang 或 MinGW 而不是 MSVC就需要写一个 toolchain 文件通过-DCMAKE_TOOLCHAIN_FILE指定。用 3.10 时toolchain 文件里常见的写法包括set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_C_COMPILER clang) set(CMAKE_CXX_COMPILER clang) set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -fms-compatibility)类似这样。要注意的是CMake 3.10 对 Clang 在 Windows 上的支持还不如现在成熟如果报一些莫名其妙的链接错误可以先试试用-G Visual Studio 15 2017配合 MSVC 生成排除 toolchain 本身的问题。4. 再聊聊执行 bash 命令和预编译的另类思路4.1 在 CMake 中执行 bash 命令的正确姿势热词里有cmake执行bash命令很多从 Linux 迁过来的同学喜欢在 CMake 里调bash -c ...来做一些预处理。CMake 本身提供了execute_process它可以在配置阶段执行任意命令。比如你想在 CMake 配置时获取当前 git 短哈希execute_process( COMMAND bash -c git rev-parse --short HEAD WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} OUTPUT_VARIABLE GIT_HASH OUTPUT_STRIP_TRAILING_WHITESPACE )这样GIT_HASH就会变成一串短哈希。但这里有几个必须注意的地方bash必须在你当前系统的 PATH 中。Windows 上通常来自 Git Bash 或 WSL。如果你的目标是调用 WSL 里的工具用wsl bash -c ...更靠谱。如果命令执行失败execute_process默认并不报错只是把返回码存在RESULT_VARIABLE中。你需要在后面手动判断execute_process(COMMAND bash -c false RESULT_VARIABLE ret) if(NOT ret EQUAL 0) message(FATAL_ERROR bash command failed: ${ret}) endif()不要把execute_process和自定义命令混为一谈。execute_process是在 CMake 配置阶段执行的也就是你敲cmake ..的时候执行而add_custom_command是在构建阶段执行的也就是你按 F5 编译的时候执行。如果你想要“每次编译前自动跑 bash”应该用add_custom_command(TARGET xxx PRE_BUILD COMMAND bash -c ...)而不是execute_process。4.2 预编译的写法本质是在缓存编译产物回到预编译头很多新手以为“预编译”是 CMake 的功能其实完全是编译器的功能。CMake 只是负责把对应的命令行参数传给编译器。MSVC 的/Yc表示创建预编译头/Yu表示使用预编译头。CMake 3.10 不支持高层的封装你只能用最原始的方式拼参数。在实际项目中如果一定要在 3.10 上把预编译头跑通我有一个折中方案写一个独立的cmake/precompiled.cmake脚本集中维护所有预编译头相关定义然后用include()引入。脚本里可以这样写macro(enable_pch_header target pch_header pch_source) set_source_files_properties(${pch_source} PROPERTIES COMPILE_FLAGS /Yc${pch_header}) target_sources(${target} PRIVATE ${pch_source}) target_compile_options(${target} PRIVATE /Yu${pch_header} /Fp${CMAKE_CURRENT_BINARY_DIR}/${target}.pch) endmacro()用这个宏之后至少不用在每个源文件里重复写/Yu。注意这里的/Fp要统一指向同一个.pch文件否则编译时找不到。而更现代的做法还是升级 CMake 后用target_precompile_headers。看到这里你应该已经明白很多“CMake 怎么做 X”的问题答案往往不是“CMake 提供了 Y”而是“这取决于你的编译器CMake 只是传话人”。5. 常见问题与排查技巧实录5.1 无法找到 cmake.exe 或“不是内部或外部命令”这类问题九成是 PATH 没配好。但还有一种隐蔽情况你确实加了 PATH但 CMake 的版本冲突。系统里装了 Python 自带的 CMake或者 Anaconda 里的 CMake它们的路径排在前面。命令行里敲cmake --version显示的可能是别的版本。这时候用where cmakeWindows 自带查看实际调用的路径。where cmake输出会列出所有出现在 PATH 里的 cmake.exe第一个就是当前生效的。如果发现不是你要的 3.10.0要么调整 PATH 顺序要么直接把D:\dev\cmake-3.10.0-win64-x64\bin挪到最前面。另一个原因是终端没有重启环境变量不会自动刷新。还有如果是用 PowerShell某些编辑器不会读取最新的用户环境变量需要重启编辑器或操作系统一次。5.2 CMake 生成 VS 工程时选错 generator3.10.0 默认支持的 VS 版本最高是 Visual Studio 15 2017。如果你装了 VS2022直接运行cmake ..时会报CMake Error at CMakeLists.txt:... (project): No CMAKE_C_COMPILER could be found.或者Could not find a matching installation of Visual Studio.这是因为 3.10 不认识 VS2022 的实例。解决思路有三个一是用-G Visual Studio 15 2017强制指定老版本 generator但前提是你机器上确实装了 VS2017二是用 Ninja 生成器绕过 VS 版本检测但需要单独装 Ninja三是老老实实下载新版 CMake。如果你今天刚拿到cmake-3.10.0-win64-x64.rar而电脑上只有 VS2022我的建议是放弃 3.10换用 3.20 以上的版本否则一路都是坑。但如果你想维护老工程又只有新 VS只能采用第二种方案装 Ninja 然后用cmake -G Ninja ..对这个场景而言Ninja 的配置更简单。5.3 路径带空格或者中文引发的问题CMake 对路径中的空格支持得不错但前提是路径里的空格都放在引号中。最常见的错误是在execute_process或add_custom_command里拼接路径时少了引号比如execute_process(COMMAND mytool.exe ${INPUT_PATH})如果INPUT_PATH是C:\Program Files\xx\input.txt那就会把Program和Files\xx\input.txt当成两个参数。老手会写成execute_process(COMMAND mytool.exe ${INPUT_PATH})但 CMake 会保留引号吗这取决于当前平台。在 Windows 上CMake 通常会自动为带空格的参数加引号但用bash -c时就会出问题因为 bash 的引号解析和 Windows 命令行不同。另一个情况是中文路径。CMake 3.10.0 对中文路径的支持不是很好尤其是当路径里有中文且代码文件用了非 UTF-8 编码时很容易报 “Invalid character”。建议开发环境的所有路径都使用纯英文加数字这是一个低成本但极其有效的避坑技巧。还有一点构建目录本身最好不要放在需要管理员权限的路径下比如C:\Program Files。不然每次 build 都可能遇到权限问题非常烦人。这个和 CMake 无关但和 Windows 下开发体验强相关。最后的一点个人体会玩 CMake 这么些年我越来越觉得版本和工具只是表面核心还是理解“生成”和“构建”的分离。cmake-3.10.0-win64-x64.rar这个老包如果你只是想快速生成一个 VS 工程它绝对够用但如果你想玩预编译头、toolchain、跨版本 VS那真的建议顺手去官网下个 3.20几兆的东西省下的是大把调试时间。要是遇上不能上外网的环境那就在内网搭个本地共享目录把这几个版本都放进去随用随取。最后再分享一个小技巧拿到任何 CMake 安装包后第一时间用cmake --version确认路径生效用cmake --help确认可用的 generator。这两条命令会帮你省掉一半的“运行不了”的困惑。本文还有配套的精品资源点击获取
