简介：面向Windows 64位平台的CMake 3.10.0安装包，适用于需要在Windows环境中开展跨平台构建工作的开发者、项目维护者与初学者。CMake是开源构建系统，不直接编译代码，而是读取项目中的CMakeLists.txt配置，解析目标、源文件、依赖与编译选项，再生成Visual Studio解决方案、Ninja或Unix Makefiles等构建文件，适合大型项目、多编译器和多平台的统一管理。压缩包（rar格式）约18.61MB，解压后即可使用cmake-gui或命令行工具，通过find_package、include_directories、add_subdirectory、install、option等命令完成外部依赖查找、头文件路径设置、子目录引入、安装步骤与可选配置项定义，还可借助工具链文件适配不同编译器或交叉编译环境。3.10.0版本在先前基础上包含若干修复与新模块，对构建流程有所优化。已有1677人学习浏览，利用它可快速搭建CMake环境，降低多项目构建的配置成本，也为掌握生成器、变量以及CTest、CPack等配套工具提供完整入口。
1. cmake-3.10.0-win64-x64.rar 安装包：一个“老但没死”的 Windows 构建工具
很多人在复现旧工程、下载历史版本源码或者接手 2018 年前后的 C++ 项目时，都会碰到cmake-3.10.0-win64-x64.rar这个安装包。它不是最新版，也不是绿色免安装工具，而是 CMake 3.10 官方二进制被第三方重新打包成 rar 后的分发形态。把它正确装好，本质上就是给 Windows 装上一个能把CMakeLists.txt翻译成 Visual Studio 工程、再驱动编译器产出 exe 的构建入口。这篇文章我按“安装包拆解 → 安装与 PATH 配置 → 最小工程验证 → 典型踩坑 → 进阶用法”的顺序，把从解压到跑通完整构建的整个过程讲透。适合刚接触 CMake 的读者，也适合需要在老版本环境里复现旧项目的熟手。
2. 拆解 cmake-3.10.0-win64-x64：版本选型与安装包命名里的信息量
拿到这个 rar，先别急着解压。文件名里每一段都藏着信息：3.10.0是版本号，win64-x64说明这是 64 位 Windows 的二进制包，.rar则暗示它不是官方直发形式。把这三件事搞清楚，后面的安装才不会走弯路。
2.1 为什么老项目还抱着 3.10.0 不放
CMake 3.10.0 发布于 2017 年底，距今已经过去很多年，但它在旧工程复现场景里依然是高频出现的版本。原因很直接：相当一批 2018 到 2019 年之间发布的开源工程，CMakeLists.txt第一行写的是cmake_minimum_required(VERSION 3.10)，后续维护也没有跟着新版语法迁移。用新版本 CMake 去构建这些工程，多数时候能过，但会冒出一堆 deprecation 警告，甚至某些老式find_package模块的搜索行为在新版里被调整过，导致同一个工程在新版上反而链接失败。
我一般见到3.10.0出现在安装包文件名里，第一反应是“这台机器上大概率要编一个锁死版本的项目”。CMake 3.10 恰好站在一个舒服的位置：它已经有了target_compile_features、add_compile_options这些成熟的现代写法，同时又还没引入后来若干破坏性变更。对于只想把旧代码跑起来、不想折腾兼容性的场景，锁 3.10.0 是成本最低的选择。
2.2 win64-x64：这是 CMake 程序位数，不是你的目标平台
win64-x64表示 CMake 程序本体是 64 位 Windows 可执行文件，仅此而已。很多人误以为这个包生成的工程一定是 x64 的，这是个高频率误解。CMake 生成什么架构的工程，取决于你传给-G的生成器和-A指定的平台参数，而不是 CMake 程序本身的位数。
| CMake 安装包命名 | 程序位数 | 目标平台决定方式 |
|---|---|---|
| win32-x86 | 32 位 CMake 程序 | 由-G/-A决定 |
| win64-x64 | 64 位 CMake 程序 | 由-G/-A决定 |
例如同样用这个 64 位 CMake，-A x64生成 64 位工程，不写-A则默认生成 Win32 工程。32 位系统装不了win64-x64这个包，得找win32-x86版本。
2.3 .rar 安装包的两种形态与分流处理
官方发布的 CMake Windows 包一般是.exe安装程序或.zip压缩包。.rar是第三方重新打包的，打开方式要分情况处理。解压后，里面可能是两样东西之一：一个.msi安装文件，或者一整个 CMake 目录（包含bin、doc、share）。
如果是.msi，直接走安装向导，CMake 会把自己装进Program Files或你指定的目录；如果是一整个目录，那这就是绿色版，不需要安装，只需要把bin目录加进 PATH 就能用。判断方法很简单：解压后第一眼看到的是单个.msi还是好几个文件夹。另外，第三方的 rar 解压时杀毒软件误报率不低，解压完成后先确认cmake.exe和cmake-gui.exe还在不在，再继续安装，这一步能省掉后面许多莫名其妙的“找不到命令”问题。
3. 把安装包变成能用的 cmake 命令：安装向导、PATH 配置与静默安装
无论 rar 里是 msi 还是绿色目录，目标都一样：让cmake这个命令在任何新开的终端里都能直接执行。这一章讲两条路线，以及验证安装是否成功的关键命令。
3.1 解压目录与安装向导里的三个关键选项
如果 rar 里是.msi，双击进入安装向导。我强烈建议你手动把安装路径改成C:\tools\cmake-3.10.0-win64-x64，而不是默认的C:\Program Files\CMake。原因有二：路径不含空格，后续命令行操作省掉一堆引号转义；路径够短，写进 CMake 脚本或者工具链文件时不会因为路径字符串拼接出问题。
安装向导里有一个选项叫 “Add CMake to the system PATH for all users”，一定要勾上。这个是新手最容易漏的一步，漏了之后cmake命令在任何终端里都找不到。另外两个选项“创建桌面快捷方式”和“创建开始菜单目录”无关紧要，按需勾选。
安装完成后，检查一下安装目录里是否有bin、doc、share三个子目录，其中bin下应该有cmake.exe、cmake-gui.exe、ctest.exe、cpack.exe四个可执行文件。缺任何一个是解压阶段被安全软件清理了，建议重新解压并加白名单。
3.2 命令行静默安装与 PATH 的两种设置途径
批量化部署时不方便弹向导，可以用 msiexec 做无人值守安装：
msiexec /i cmake-3.10.0-win64-x64.msi /qn ADD_CMAKE_TO_PATH=System参数说明：/qn表示完全静默，不弹出任何界面；ADD_CMAKE_TO_PATH是 CMake 官方 MSI 包的公开属性，System值表示写入系统级 PATH，User值表示只写入当前用户的 PATH。注意，如果之前手动装过别的版本 CMake，/qn静默安装不会给出冲突提示，装完后务必用下面一节的方式确认版本号。
如果 rar 里是一整个绿色目录，不需要安装，但需要手动把bin目录加进 PATH。不推荐用setx PATH "%PATH%;C:\tools\cmake-3.10.0-win64-x64\bin"这种方式，因为setx有 1024 字符的截断风险，会把原有 PATH 写坏。我一般用 PowerShell：
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\tools\cmake-3.10.0-win64-x64\bin", "User")这段代码把 CMake 的 bin 目录追加到当前用户的环境变量 Path 里。参数说明：$env:Path是当前进程的 PATH 值；"User"表示写入用户级环境变量，不需要管理员权限；如果想写系统级，用"Machine"但必须开管理员权限。写入后要新开终端才会生效。
3.3 验证安装：cmake --version 与 where cmake 各看什么
安装完第一件事是验证，两个命令配合使用：
cmake --version where cmakecmake --version输出第一行是版本号，正常情况下会看到cmake version 3.10.0，后面跟着平台信息。where cmake输出的是命令解析到的完整路径，用来确认你调用的到底是哪个目录下的 cmake。这一步非常关键：有些机器上装了别的大软件自带了一份 cmake，如果你发现where cmake指向的路径不是你刚安装的C:\tools\...，说明 PATH 顺序被占了，后续构建很可能用到错误的版本。遇到这种情况，把新装目录挪到 PATH 最前面，或者干脆删掉旧的那份，二选一。
4. 用最小工程验证环境是否真能干活：从 CMakeLists.txt 到可执行文件
cmake --version能跑只是第一步，真正要确认的是“这个 CMake 能不能配合你机器上的编译器产出可执行文件”。这一章用最简工程把完整链路走一遍。
4.1 最小 CMakeLists.txt：版本声明、语言声明与目标定义
新建一个目录hello/，里面放两个文件。先写CMakeLists.txt：
cmake_minimum_required(VERSION 3.10) project(hello LANGUAGES CXX) add_executable(hello main.cpp)这段配置的逻辑说明：第一行声明最低 CMake 版本，在 3.10.0 上运行不会有版本策略告警；第二行project(hello LANGUAGES CXX)声明工程名和语言，LANGUAGES CXX告诉 CMake 只需要检测 C++ 编译器，如果你还用了 C，就写成LANGUAGES C CXX；第三行add_executable定义可执行目标，第一个参数是目标名，第二个参数是要编译的源文件。注意project()的语言参数必须大写，写小写会在较老版本上报错。
再写main.cpp：
#include <iostream> int main() { std::cout << "cmake 3.10.0 works" << std::endl; return 0; }这个文件只做一件事：打印一行字符串，用于确认生成的可执行文件能正常加载运行时库。
4.2 用 Visual Studio 15 2017 生成器跑通一次完整构建
CMake 本身不编译代码，它负责生成工程文件，再调用编译器完成实际构建。在 Windows 上最常见的生成器是 Visual Studio。给 3.10.0 搭配的稳妥生成器是 Visual Studio 15 2017，也就是 VS 2017：
mkdir build cd build cmake .. -G "Visual Studio 15 2017" -A x64 cmake --build . --config Release前三行创建一个独立的构建目录并进入，cmake ..指定源码目录为上一级，-G指定生成器，-A x64指定目标平台为 64 位。配置成功后，cmake --build . --config Release执行实际编译链接，--config指定的配置类型只对多配置生成器有意义，对应 Visual Studio 里的 Release 配置。
这段流程为什么不写成cmake -S . -B build？因为-S和-B这种参数形式在新版本 CMake 里是标准写法，但在 3.10.0 上并不稳妥。老版本上最保险的用法就是cd build && cmake ..。装老版本的目的就是复现老工程，命令行习惯也应该跟着老版本走，这是减少不确定性的一个细节。
4.3 构建产物在哪：build 目录与多配置生成器
构建完成后，build/目录下会出现一个Release子目录，里面躺着hello.exe。这是因为 Visual Studio 生成器属于多配置生成器：Debug 和 Release 的编译选项在配置阶段就同时准备好了，构建时用--config指定哪一套，输出目录自然按配置名分文件夹。
| 生成器类型 | 代表生成器 | 构建产物目录 | 配置时机 |
|---|---|---|---|
| 多配置 | Visual Studio | build/<配置名>/ | 构建时用--config指定 |
| 单配置 | MinGW Makefiles | build/ 根目录 | 配置时用CMAKE_BUILD_TYPE指定 |
如果你换成 MinGW 或 Unix Makefiles 这类单配置生成器，输出目录里就没有Release这一层，而是直接用cmake配置时-DCMAKE_BUILD_TYPE=Release决定的。理解这个差异，找.exe的时候能少走弯路。
运行一下验证：
.\Release\hello.exe看到cmake 3.10.0 works输出，说明 CMake、生成器和编译器三者之间完全没有兼容性问题，这套环境可以交给任何需要 3.10.0 的旧项目使用了。
5. 安装与初用阶段的 5 个典型坑：现象、原因与解决
老版本软件在 Windows 上的坑比较集中，这里选 5 个最常见的写下来，每一条都是“现象 → 原因 → 解决”的结构。这些坑多数不是玄学，本质都是环境变量、版本边界和路径细节。
5.1 新开终端还是找不到 cmake 命令
现象：安装时明明勾了 “Add CMake to PATH”，安装完新开一个黑窗口输入cmake却提示不是内部或外部命令。原因：终端进程启动时读取的是当时的环境变量快照，如果新开的终端是从某个旧进程（比如资源管理器）继承来的，PATH 不一定刷新。解决：关掉所有终端窗口和资源管理器，重新开一个；如果还不行，运行where cmake和 PowerShell 的$env:Path，确认安装目录确实在 PATH 里。这一步能把 80% 的“装了不能用”问题一次性排除。
5.2 cmake-gui 启动报错或提示缺运行库
现象：命令行 cmake 完全正常，但双击cmake-gui.exe弹窗报错，或者提示缺少某运行库无法启动。原因：CMake 图形界面在 Windows 上依赖 .NET Framework 运行库，精简版系统或 Server Core 环境经常缺。解决：如果你只需要构建，直接用命令行 cmake 即可，完全绕开 GUI；确实需要图形界面的，安装对应版本的 .NET Framework 后再启动。
5.3 同一份 CMakeLists.txt 在新版能编，在 3.10.0 上翻车
现象：工程在装了新版 CMake 的机器上一切正常，拿到这台 3.10.0 上报错，报错信息类似unknown argument或not found。原因：CMakeLists.txt 里用了 3.10.0 发布之后才加入的语法或命令，比如在新版本里常见的target_link_options（3.13 加入）或string(JSON ...)（3.19 加入）。3.10.0 根本不认识这些命令，自然报错。解决：先看文件头部的cmake_minimum_required声明——如果它本身写的是 3.16，那是工程主动选择高版本，与 3.10.0 无缘；如果声明确实是 3.10，那就是工程里混入了高版本特性的代码，顺着报错行改回旧语法。这是老版本复现里最真实的一类问题，没有捷径，只能逐行排查。
5.4 路径含空格或中文导致配置阶段直接失败
现象：配置阶段报错类似The source directory does not exist，或者生成阶段某个第三方模块找不到文件，但路径明明是对的。原因：源码路径或 CMake 安装路径里有空格、中文和特殊字符。CMake 本身对空格处理得还可以，但很多第三方Find*.cmake模块拼接路径时不加引号，路径一复杂就炸。解决：安装 CMake 时用C:\tools\cmake-3.10.0-win64-x64这种无空格路径，源码目录也尽量放在C:\work这类纯英文路径下。这是踩过最深的一次坑，后来养成了路径里绝不出现中文的习惯。
5.5 用 3.10.0 配 VS 2019：生成器识别不到编译器
现象：cmake .. -G "Visual Studio 16 2019"配置后报错，提示找不到编译器或无法识别 Visual Studio 实例。原因：CMake 对 VS 2019 的正式支持从 3.14 才开始，3.10.0 发布时 VS 2019 还不存在，它自然认不出这一代编译器。解决：老版本 CMake 配老版本 VS，3.10.0 的最佳搭档是 VS 2017（生成器名Visual Studio 15 2017）；如果机器上只有 VS 2019，那要么升级 CMake，要么让项目保持旧语法。遇到这种情况，我的选择是直接换新版 CMake，不为一个老版本牺牲整个工具链。
6. 把 3.10.0 用出高级感：缓存预置与离线迁移两个技巧
最后给两个实际工作中最常用、但新手不太会主动查的技巧：预置缓存配置和整目录离线迁移。两个技巧都用得上 3.10.0，且不依赖更高版本特性。
6.1 用 -C 脚本预置缓存，把问答环节一次做完
首次配置 CMake 时，有些变量交互式询问，很浪费时间。可以写一个预加载脚本，让 CMake 在读取 CMakeLists.txt 之前就把缓存变量定好：
# cache-init.cmake set(CMAKE_BUILD_TYPE Release CACHE STRING "" FORCE) set(CMAKE_INSTALL_PREFIX "C:/tools/hello-install" CACHE PATH "" FORCE)cd build cmake .. -C ../cache-init.cmake -G "Visual Studio 15 2017" -A x64-C参数指定预加载脚本，脚本里CACHE ... FORCE强制覆盖已有缓存值。注意，-C只在首次配置时生效，如果 build 目录里已经存在 CMakeCache.txt，再执行这条命令不会更新变量，必须删掉整个 build 目录重来。如果做交叉编译，最好也把CMAKE_TOOLCHAIN_FILE写进这个脚本，一次配好，避免每次手输一长串-D参数。
6.2 离线迁移：整目录拷走加 PATH 脚本
绿色版 CMake 最大的价值是离线迁移。把整个cmake-3.10.0-win64-x64文件夹拷到另一台机器，不用安装，只要配好环境变量就能用。因为bin目录下的cmake.exe依赖同目录的若干 DLL，share目录里是各模块文件，三个目录必须整份带走。
迁移后可以写一个环境初始化脚本，避免手工改系统环境变量：
@echo off set PATH=C:\tools\cmake-3.10.0-win64-x64\bin;%PATH% cmake --version这段批处理把 CMake 的 bin 目录临时加到当前命令行的 PATH 前部，并打印版本号确认生效。用在 CI 机器的构建脚本开头很合适，不污染系统级环境变量，也不用担心 setx 截断 PATH 的问题。
我现在的习惯是：遇到必须锁 3.10.0 的环境，第一件事永远是看CMakeLists.txt头部的版本声明，第二件事是确认机器上 Visual Studio 的版本，最后才去找安装包。顺序反了，就会在 5.5 那种兼容性问题上白白耗掉一下午。希望帮到你。
本文还有配套的精品资源，点击获取
