简介这是一份面向Windows 64位平台的CMake 3.10.0安装包适合需要在Visual Studio、Ninja等生成器环境下管理C/C项目构建的开发者使用。CMake不直接编译代码而是通过CMakeLists.txt定义目标、源文件、依赖关系和编译配置再生成对应平台的构建文件。资源包为rar压缩格式体积约18.61MB由于上游未提供文件清单具体文件构成暂无法列出。已有1675人浏览学习。借助这份安装包可以系统掌握CMake的核心机制包括CMakeLists.txt中的project、add_executable、target_link_libraries等命令理解find_package、include_directories、option等常用指令以及如何处理多目录项目、配置工具链文件、生成VS解决方案或Ninja构建文件。还可以通过set、message等命令调试配置过程借助工具链文件适配不同编译器。对正在学习跨平台构建或准备搭建自动化构建流程的开发者来说这是一份实用的基础工具资源。 如果你手里正好有一个 cmake-3.10.0-win64-x64.rar下载完之后大概率会停顿一下这到底怎么装装完又要干什么这个问题我被人问过不下十次尤其是刚接触 C 的同事从某个内部软件平台拖下这个压缩包解压后看到一堆英文目录直接懵了。其实 CMake 3.10.0 是一个非常经典的 Windows 64 位 CMake 版本到今天仍有大量老项目、嵌入式 SDK、VS2017 工程在用。这篇文章我从安装包本身开始讲一直延伸到环境配置、生成 VS 工程、输出路径控制、toolchain 文件、bash 命令调用和预编译头处理全程用实际项目中验证过的做法展开希望能帮你把这个老版本用得明明白白。1. 版本号与架构命名背后的事1.1 为什么现在还有人抱着 3.10.0 不放说真的CMake 现在新版本已经出到 3.30 以上了3.10.0 属于“老前辈”。但正是这个老前辈在很多团队里活得很好。哪些人还在用我总结下来主要是两类场景。一类是存量老项目。有的工程从 2017 年、2018 年就建立了CMakeLists.txt 里写的 cmake_minimum_required(VERSION 3.10)后面接了一大堆第三方库、自定义脚本和内部工具链。这种项目如果贸然升级 CMake轻则警告变多重则某些 FindXXX.cmake 模块行为变化导致链接失败或者头文件路径解析出错。对于做产品交付的团队来说构建系统能不动就不动稳定压倒一切。另一类是旧编译器的绑定需求。CMake 3.10.0 对 Visual Studio 2017 的支持已经相当成熟而很多公司内部的 CI 构建服务器依然用 VS2017配合 CMake 3.10.0 跑了好几年都没出过大问题。你让运维去升级人家第一句话就是“现在不是跑得好好的吗”。所以“版本旧”不等于“不能用”。关键是你得清楚 3.10.0 的能力边界在哪里比如它不会认识 VS2019、VS2022 的 generator也没有 target_precompile_headers 这种后来才加入的高级命令。搞清楚边界这个老版本依然能干活。1.2 win64-x64 和 rar 这两个后缀分别意味着什么win64-x64 指明这是运行在 Windows 64 位系统上的 CMake 可执行程序。你注意它说的是 CMake 这个工具本身是 64 位的不是说用它能编译出来的目标程序必须 64 位。你在 64 位 Windows 上用 cmake-gui.exe 配置一个 32 位的 C 工程完全没问题编译出来的是 x86 程序还是 x64 程序取决于你选择的编译器工具链和 generator。后缀是 rar这是因为你拿到的可能是第三方站点重新打包的分发版本。CMake 官方其实更常分发 zip 和 exe 安装程序但很多下载站会把 zip 再压一层 rar。解压后本质上是绿色免安装版这一点没坑。解压后目录结构值得先看一眼否则配置 PATH 时容易搞错层级bin/核心工具所在cmake.exe、cmake-gui.exe、ctest.exe、cpack.exe 都在这里share/cmake-3.10/CMake 内置的 Modules、Templates 和帮助文档doc/cmake-3.10/离线文档适合偶尔快速查命令licenses/开源许可证文本记住环境变量 PATH 要指向 bin 目录不是指向解压后的总目录。我见过有人把整个 cmake-3.10.0-win64-x64 加进 PATH结果命令行里敲 cmake 还是提示找不到命令反而开始怀疑是不是包有问题。2. 解压、配置 PATH 与验证安装2.1 解压路径选择的讲究你可能觉得解压路径随便放就行其实不然。CMake 在生成工程时会记录大量路径信息路径越短越稳定后续问题越少。我个人的习惯是在某个盘的根目录下建 tools 文件夹例如 D:\dev\tools\cmake-3.10.0-win64-x64。不建议放到 C:\Program Files 下面那种带空格的路径。虽然现代 CMake 对带空格路径的支持已经不错但在 3.10.0 这个年代有些第三方脚本、自定义命令拼接路径时只要少了一层引号处理空格就会变成噩梦。同样项目代码目录也尽量别用中文路径这个我在后面第 6 节还会详细说。解压用 WinRAR、7-Zip、Bandizip 都行步骤没什么可讲的。解压完先别急着关到 bin 目录确认一下 cmake.exe、cmake-gui.exe、ctest.exe 都在尤其是 ctest.exe很多人后面做自动化测试才会发现它不见了。2.2 PATH 环境变量一步步配好右键“此电脑”属性高级系统设置环境变量。在用户变量或者系统变量的 Path 中新增一行 D:\dev\tools\cmake-3.10.0-win64-x64\bin我习惯加到用户变量这样不影响系统里其他账户。加完后有个极易踩的坑你现在已经打开的 cmd 窗口不会立即识别新的 PATH必须新开一个终端。很多人配完环境变量在旧窗口敲 cmake 没反应就以为没配成功其实只是终端没刷新。新开 cmd 或 PowerShell输入 cmake --version正常会输出类似 cmake version 3.10.0 的字样。如果提示“无法将 cmake 识别为 cmdlet 或命令”先检查 PATH 路径是否真的指向 bin 目录以及 bin 下面的文件名是不是 cmake.exe 而不是 cmake.exe.exe 这种畸形命名。2.3 两种验证方式命令行和图形界面命令行验证自然是 cmake --version它能确认程序可执行。图形界面验证则是启动 cmake-gui.exe主界面左上角会显示版本信息整个窗口能正常打开就说明 Qt 依赖没问题。关于 cmake-gui 多说一句它是图形化的 CMake 配置工具左边是源码目录和构建目录右边是各种缓存变量很多老工程师喜欢用它来改选项和看日志确实比纯命令行直观。刚才还有人会问双击 bin/cmake.exe 后窗口一闪而过是不是包坏了不是。cmake.exe 本身就是命令行程序双击它没有参数可执行终端窗口自然秒关。想图形化操作用 cmake-gui.exe不要双击 cmake.exe。3. 最小工程验证让 CMake 真正“转”起来3.1 从零写一个能编译的最小工程安装验证通过只代表 CMake 程序可以运行了并不代表它能配合 Visual Studio 正常干活。我建议你立刻建一个最小工程把整个构建闭环跑通。目录结构很简单C:\work\demoCMakeLists.txt main.cppCMakeLists.txt 内容cmake_minimum_required(VERSION 3.10) project(demo) add_executable(demo main.cpp)main.cpp 内容#include iostream int main() { std::cout hello cmake std::endl; return 0; }打开命令行进入 C:\work\demo执行mkdir build cd build cmake .. -G Visual Studio 15 2017这里有个很关键的概念generator。generator 决定 CMake 生成什么类型的构建系统。在 Windows 上最常用的是 Visual Studio 生成器它会输出一个 .sln 解决方案和若干 .vcxproj 工程文件。CMake 3.10.0 支持的最高 VS 版本就是 VS2017也就是 Visual Studio 15 2017。如果机器装的是 VS2019 或 VS2022你要么升级 CMake 到一个新版本要么就只能用 VS2017。3.2 为什么坚持用 build 目录很多人初学时不理解为什么要在项目目录下面再建一个 build 目录直接 cmake . 不更方便吗原因有两条。第一源码目录能保持干净。直接在根目录执行 cmake .会在源码目录生成 CMakeCache.txt、CMakeFiles 文件夹、cmake_install.cmake 等一堆中间产物。这些文件不该出现在 git 仓库里如果忘了在 .gitignore 里排除很容易误提交。第二同一个源码目录可以同时存在多套构建配置。比如你可以在项目根目录下建 build-vs2017、build-mingw、build-linux 多个目录分别对应不同工具链和不同配置互不干扰。想清理重新构建时直接删掉对应的 build 目录比在 CMake 里各种折腾缓存变量痛快得多。执行完 cmake .. 后build 目录中会出现 demo.sln。用 VS 打开它把 demo 设为启动项目直接 CtrlB 编译、CtrlF5 运行如果控制台输出 hello cmake恭喜你CMake 3.10.0 在你的机器上已经完整跑通了。4. VS 工程里最扎心的几个路径问题4.1 源码路径的相对写法关于“cmake 生成的 VS 工程使用相对路径的写法”这是新项目从零搭建或者老工程迁移时最容易纠结的一点。先说结论在 CMakeLists.txt 里写源码文件时应该用相对于当前 CMakeLists.txt 文件的路径不要拼绝对路径。例如add_executable(demo src/main.cpp src/common/util.cpp src/common/logger.cpp )CMake 会自动把这里的 src 前缀解析为当前 CMakeLists.txt 所在目录下的 src 路径。这样整个源码工程拷贝到任何一台机器上只要目录的相对结构不变重新 cmake 一下就能用不需要改任何配置。如果你确实需要在 CMakeLists.txt 里引用某个固定位置的文件比如第三方开源库不要手写 C:/Users/xxx/...要使用 CMake 内置的变量CMAKE_CURRENT_SOURCE_DIR当前 CMakeLists.txt 所在目录CMAKE_CURRENT_LIST_DIR当前文件所在目录include 其他 cmake 文件时比上面那个更准确CMAKE_SOURCE_DIR顶层源码目录CMAKE_BINARY_DIR顶层构建目录实际写的时候类似这样set(THIRD_PARTY_DIR ${CMAKE_CURRENT_LIST_DIR}/third_party) include_directories(${THIRD_PARTY_DIR}/include)这样工程整体移动后路径依然能正确解析不会出现“在别人机器上编译报找不到头文件”的尴尬。另外有个细节很多人没注意CMake 生成 VS 工程时源文件在 .vcxproj 里其实是以相对路径形式登记的。这意味着 build 目录可以整体搬迁。假如你在一台机器上配置好把整个 build 目录拷到另一台相同环境的机器很多情况下不用重新 cmake 也能直接打开工程编译。4.2 输出目录如何去掉 Debug 子目录热词里有一条是“cmake 输出路径去掉 debug”这个问题在 VS 多配置生成器下非常典型。默认情况下你用 VS 生成器构建输出的 exe、dll 会被放到 build\Debug\ 和 build\Release\ 这样的子目录中。有些人觉得很不方便希望所有配置产物统一丢到一个目录里。CMake 提供了三个目录控制变量CMAKE_RUNTIME_OUTPUT_DIRECTORY可执行文件和 DLL 的输出目录CMAKE_LIBRARY_OUTPUT_DIRECTORY动态库的输出目录CMAKE_ARCHIVE_OUTPUT_DIRECTORY静态库 .lib 的输出目录在 project() 后面加上set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)这样再生成 VS 工程所有配置的 exe 和 dll 都会直接进到 build/bin不再带 Debug 或 Release 子目录。如果只想单独修改某个 target 的输出目录用 target propertyset_target_properties(demo PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin )这里必须提醒一个坑Debug 版和 Release 版都输出到同一个目录时同名 exe 会互相覆盖。如果你只开发 Debug集中输出确实方便但如果你需要同时保留多个配置的构建产物给测试或者打包最好还是保留 Debug/Release 子目录然后在后续的打包脚本里按配置拷贝。反正我实际负责过的一个项目就是因为贪图“去掉 Debug”方便结果 CI 上两个配置并行构建时互相抢文件排错排了半天才反应过来。4.3 调试工作目录也要一起管路径相关的另一个高频问题是在 VS 里点击调试后程序加载不到运行目录下的配置文件。比如你的程序前面有个 config.ini放在 bin 目录下调试启动时却提示找不到。这是因为 VS 调试时的工作目录默认是 .vcxproj 所在目录而不是可执行文件所在目录。CMake 里可以用 VS_DEBUGGER_WORKING_DIRECTORY 这个 target property 解决set_target_properties(demo PROPERTIES VS_DEBUGGER_WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin )设置完重新生成工程调试启动时程序的工作目录就变成了 build/bin相对路径读取配置文件的行为也会符合你的预期。这个属性在 CMake 3.10.0 中已经支持老版本用户的体验会好很多。5. 老版本 CMake 的进阶操作边界5.1 用 toolchain 文件固定交叉编译工具链“cmake toolchain”是嵌入式开发和固定编译器环境时的核心玩法。toolchain 文件本质上是一段在 configuration 最开始阶段就被加载的 CMake 脚本用来告诉 CMake 你用的是哪套编译器、目标系统是什么、处理器架构是什么。一个典型的 ARM 交叉编译 toolchain 文件长这样set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER D:/dev/gcc-arm-none-eabi/bin/arm-none-eabi-gcc.exe) set(CMAKE_CXX_COMPILER D:/dev/gcc-arm-none-eabi/bin/arm-none-eabi-g.exe) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)使用方式cmake .. -DCMAKE_TOOLCHAIN_FILED:/dev/toolchain-arm.cmake关键点在于不要把编译器路径直接写在项目 CMakeLists.txt 里。因为在 project() 之后再写 set(CMAKE_C_COMPILER ...) 很有可能不生效CMake 在 project() 阶段就已经完成编译器探测了之后设置已经晚了。而 toolchain 文件是在 project() 之前被读入的所以能真正改变编译器选择。如果你只是想在 Windows x64 上固定使用 MinGW-w64 而不是 Visual Studio也可以写一个 toolchain 文件但 CMAKE_SYSTEM_NAME 不要写 Generic直接不写或者写成 Windows否则 CMake 会进入交叉编译模式很多系统探测逻辑会变。5.2 如何在 CMake 里执行 bash 命令“cmake 执行 bash 命令”这个需求主要分两种场景配置阶段执行和构建阶段执行。配置阶段用 execute_process。最常见的是获取 git 版本号、生成配置头文件等。示例execute_process( COMMAND bash -c echo #define VERSION 1 version.h WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} RESULT_VARIABLE result ) if(NOT result EQUAL 0) message(FATAL_ERROR bash command failed) endif()构建阶段用 add_custom_command。如果你希望每次构建时动态生成一个文件add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/generated.h COMMAND bash -c echo #define VERSION 1 ${CMAKE_BINARY_DIR}/generated.h DEPENDS some_input_file ) add_custom_target(generate_headers ALL DEPENDS ${CMAKE_BINARY_DIR}/generated.h )这里有个细节很多人会栽跟头execute_process 并不是通过 shell 来执行 COMMAND 的它直接创建进程。如果你写 COMMAND echo hello version.h在 Windows 下大于号和管道符都会被当成普通参数传给 echo结果不会得到想要的重定向效果。解决办法就是像我上面那样把整条命令包给 bash -c ...让 bash 来做重定向解析。前提是你的系统里能敲出 bash。Windows 上一般装了 Git Bash 就能找到 bash.exe路径通常在 C:\Program Files\Git\bin。如果命令行里直接敲 bash 没反应先用 find_program 定位find_program(BASH_EXECUTABLE bash PATHS C:/Program Files/Git/bin C:/Windows/System32)然后 COMMAND ${BASH_EXECUTABLE} -c ... 这样用。注意 bash 路径可能带空格必须用变量加引号的方式调用不能硬拼字符串。5.3 3.10.0 做预编译头的尴尬“cmake 指定 precompiledheaderfile”这个热词背后的真实情况是CMake 3.10.0 没有内置的 target_precompile_headers 命令。这个命令一直到 CMake 3.16 才加入。所以你在 3.10.0 上搜索怎么指定预编译头搜到的很多答案其实都是 3.16 之后的写法直接粘进工程会报“Unknown CMake command”。在 3.10.0 上想用预编译头比较常见的绕法是用一个 INTERFACE 库携带编译选项。以 MSVC 为例假设预编译头文件叫 stdafx.hadd_library(pch_header INTERFACE) target_include_directories(pch_header INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}) target_compile_options(pch_header INTERFACE $$COMPILE_LANGUAGE:CXX:/FIstdafx.h ) target_link_libraries(demo PRIVATE pch_header)这里 /FIstdafx.h 表示强制包含 stdafx.h能让每个源文件在编译前预先解析这个头文件。但说实话它更多是“强制包含”不是完整意义上的预编译。真正要生成 .pch 文件并让 MSVC 的 /Yu 和 /Yc 配合需要在 3.10.0 里手写很多细节比如单独把一个 stdafx.cpp 编成 pch还要针对不同源文件分别设置 /Yustdafx.h维护成本非常高。我的实际经验是如果项目锁死 3.10.0又确实需要预编译头来缩短编译时间先用上面这种 /FI 强制包含的方案顶着收益虽然打折但代码结构是清晰的。等将来有机会升级 CMake直接删掉这一坨换成target_precompile_headers(demo PRIVATE [[stdafx.h]])会清爽得多。6. 用 3.10.0 实战中那些“奇怪”问题安装和基础配置并不难真正消耗时间的是各种玄学问题。我把这些年遇到过的和 3.10.0 相关的问题集中列一下不一定每个人都会遇到但遇到了能少走弯路。第一个是 RAR 解压后 cmake.exe 被杀毒软件隔离。一些安全软件对老版本 CMake 的启发式扫描敏感度很高尤其是非官方渠道下载的压缩包解压出来文件可能不完整。对策是把解压目录加入白名单或者直接去官方渠道下载 zip 版解压后先跑一个 cmake --version 验明正身。第二个是“No CMAKE_C_COMPILER could be found”。这个问题在装了 VS 但没有安装“使用 C 的桌面开发”工作负载时经常出现。CMake 3.10.0 检测不到 MSVC 工具链就直接报错。解决办法是打开 Visual Studio Installer勾选“使用 C 的桌面开发”等它把 MSVC 和 Windows SDK 装好然后删掉 build 目录重新配置。注意不要只装 VS 本体而不装 C 组件很多人卡在这。第三个是 CMakeCache.txt 的缓存陷阱。当你改了 CMakeLists.txt 里的某些关键变量重新执行 cmake .. 时CMake 会优先沿用缓存里的旧值导致修改不生效。比如有人改了 CMAKE_RUNTIME_OUTPUT_DIRECTORY但输出目录还是老样子原因就是缓存没有清理。解决办法最粗暴但也最有效直接删掉整个 build 目录再重新配置。对 3.10.0 这种老版本来说手动删 build 目录比在 cmake-gui 里一个个清缓存变量可靠得多。第四个是长路径和中文路径。CMake 3.10.0 对非 ASCII 路径的支持其实比较一般虽然现代 Windows 已经支持长路径但在老版本加上老工具链的叠加下中文路径在自定义构建步骤、外部脚本、第三方工具调用时容易出现编码问题。我自己经历过一个项目放在 D:\项目\client\代码库\ 下结果预编译脚本总是找不到文件挪到全英文路径后一切正常。所以用 3.10.0 做项目源码和构建路径尽量全英文能省掉很多莫名其妙的问题。最后一个容易被忽略的点cmake --build . --config Release 这个命令里--config 是 VS 多配置生成器下区分 Debug 和 Release 的关键。很多新手以为在 CMakeLists.txt 里设置 CMAKE_BUILD_TYPERelease 就能控制 VS 的构建配置这是错的。CMAKE_BUILD_TYPE 只对 Makefile 这类单配置生成器有效对 Visual Studio 生成器根本不管用。构建配置必须在声明构建命令时用 --config 指定或者在 VS 界面上手动选。最后说点个人体会。刚接触 CMake 时我也觉得它繁琐又要理解 generator又要管 SOURCE_DIR 和 BINARY_DIR还要和各种缓存变量作斗争。但用久了你会发现CMake 的设计思路很像装修前先画图纸它的核心价值不是替你敲编译命令而是把源码、构建、安装这三个生命周期彻底拆开管理。3.10.0 虽然不是功能最全的版本但在它活跃的年代里解决了一大批 Windows 老项目的构建痛点稳定性经过了大量生产环境的验证。如果你下载了这个安装包还在犹豫装不装我的建议很简单按这篇文章的步骤先把它跑起来用最小工程确认它和 Visual Studio 的连接是通的。版本新不新不重要能把构建这件事稳定落地比什么都强。我自己手上维护的一个老项目至今用的还是 3.10.0配合 VS2017 一直很稳除非哪天业务真的需要新特性否则我不会主动去动它。本文还有配套的精品资源点击获取