简介cmake-3.10.0-win64-x64.rar 是面向Windows 64位系统的CMake 3.10.0安装包主要服务需要使用跨平台构建流程的C/C开发者、高校学生和持续集成场景的工程师。CMake本身不直接生成可执行程序而是通过CMakeLists.txt中的指令描述项目结构、源文件、头文件路径与链接库再为不同平台生成Makefile、Ninja或Visual Studio解决方案从而降低多环境维护成本。该压缩包体积约18.61MB格式为rar内含Windows 64位安装向导及配套组件安装时可按需设置环境变量安装后即可在命令行或cmake-gui中配置工程。3.10.0版本相比旧版在Find模块、依赖处理与生成器支持上有若干改进适合学习构建系统原理或快速搭建项目骨架。目前已有1676人学习下载既能作为入门CMake的实用工具也可作为团队内部统一构建版本的参考包。1. cmake-3.10.0-win64-x64.rar 是什么老项目离线装机绕不开的 3.10很多从 Qt 5.9.4、MSVC2017 时代走过来的 C 项目到今天仍然在 Windows 上用 cmake-3.10.0-win64-x64 这个安装包。它不是一个 exe 向导安装程序而是一个 rar 压缩包解压就能跑。离线环境、内网机器、版本锁定的构建服务器几乎都在用这类包把 CMake 环境一次性铺好。适合谁适合还在维护老工程、被新版 CMake 策略警告折腾过、又不想让构建行为因为版本升级突然变化的工程师。这个包能解决的就是一件事在当前机器上拿到一个行为确定、能被旧版 Visual Studio 和 Qt 正常识别的 cmake.exe并且随时能删、能换、能复制到别的机器。2. CMake 3.10 能干什么、不能干什么生成器、策略与工具链边界安装包到手之后先别急着解压。先弄清楚 3.10 这个版本在现代 Windows 构建环境里的位置不然多半会栽在“生成器对不上”这个问题上。2.1 3.10 和 VS2017、Qt 5.9 是同一代但别指望它认识 VS2022CMake 本身不编译代码它负责根据你写的 CMakeLists.txt 生成一套“别人能直接构建”的工程文件这套东西在官方术语里叫 Generator。cmake-3.10.0-win64-x64 内置的生成器大多围绕 2017 年左右的工具链常见的几个我在下表里列一下生成器名称生成的工程适用工具链备注Visual Studio 15 2017.sln / .vcxprojVS2017 全版本最常用配合 -A x64 指定 64 位Visual Studio 15 2017 Win64.sln / .vcxprojVS2017 64 位3.10 时代的老写法等价于 -A x64NMake MakefilesMakefileMSVC 命令行环境需要在 vcvarsall.bat 环境里运行MinGW MakefilesMakefileMinGW-w64 / gcc需要 mingw32-makeNinjabuild.ninjaMSVC / gcc / clang需要单独准备 ninja.exe这套生成器列表意味着什么如果你机器上只装了 Visual Studio 2022cmake-3.10.0-win64-x64 里并没有对应的生成器就算你手动输 -G Visual Studio 17 2022它也认不出这个字符串。这不是 PATH 配置问题是版本代差造成的。反过来在装好 VS2017 的机器上3.10 表现得异常稳定配合 Qt 5.9.4 的 msvc2017_64 预编译库几乎是那个时代的黄金组合。我一般会先看一眼项目根目录里有没有 CMakeLists.txt再看第一行写的 cmake_minimum_required 版本号和 target 的编译器要求再决定要不要直接上 3.10。新版本 CMake 有“策略”机制会对旧行为做兼容性切换老项目在新版下经常冒出大量 deprecation 警告甚至直接报错这是许多人反复搜“cmake 使用教程”却始终没绕出来的原因不是不会写 CMakeLists而是版本策略变了。2.2 Makefile 和 CMake 的区别装完 CMake 后你写的是什么很多从 Makefile 转过来的开发者有个困惑CMake 装完之后为什么还要写 CMakeLists.txt不能直接编译吗这里要分清两个层次。Makefile 本身是给 make 程序看的规则文件里面写死了编译命令、依赖关系、清理动作一旦换编译器、换目录结构、换平台Makefile 基本要重写。CMakeLists.txt 则是更高一层的描述你告诉 CMake“项目里有哪些源文件、需要生成一个 exe 还是一个库”由 CMake 这边生成对应平台的 Makefile、.sln 或 ninja.build 文件。所以 cmake-3.10.0-win64-x64 里那个 cmake.exe本质是一个“生成器的生成器”。它会先读取 CMakeLists.txt再结合你在命令行里传的 -G 参数吐出适合当前工具链的工程文件。理解这一点你就知道排查方向了提示如果报错发生在 configure 阶段说明是 CMakeLists.txt 或工具链识别问题如果 configure 成功但 build 报错才轮到编译器的链接、头文件、库路径问题。这个区分能帮你省大量时间。把“CMake 报错”笼统地拿去搜索往往会得到一堆牛头不对马嘴的答案。2.3 版本策略、探针机制和 3.10 的兼容边界CMake 从 3.0 开始引入策略机制每个策略对应一种老行为。新版本会把策略默认值切到新行为老项目如果没主动声明就会看到各种警告。3.10 的好处是它比 2.8 时代现代得多又不像 3.20 那样对老脚本有太多新要求。最稳妥的写法是让项目明确声明cmake_minimum_required(VERSION 3.10)这句话不只是版本检查它同时把策略等级锁在 3.10 上让构建行为可预期。另一个关键机制是编译器探针CMake 在 configure 阶段会生成一个极小的测试工程把自己检测到的编译器拿去编译验证能不能通过。网上常见报错“cmake error at /usr/share/cmake-4.2/modules/cmakedeterminecompilerid.cmake:9”本质就是新版 CMake 在 Linux 上探针失败在 Windows 上对应的是“compiler cannot compile a simple test program”这类信息。老版本 3.10 遇到新编译器比如 VS2022 的 cl 19.3x时也经常卡在探针上因为它不知道该拿哪些宏去识别这个编译器版本。所以别把 3.10 当万能钥匙。它的舒适区是VS2015/2017、gcc 57、Qt 5.95.12、MinGW-w64 早期版本。超出这个范围要么换新版 CMake要么在构建环境里先用旧编译器把 configure 阶段撑过去。3. 安装包怎么落地解压、PATH 和第一条 cmake 命令cmake-3.10.0-win64-x64.rar 的安装过程和“下一步下一步”的 exe 完全不同它是绿色解压包。这一步做对了后面所有命令都顺做错了最常见的症状是 cmd 里敲 cmake 提示不是内部或外部命令。3.1 解压到纯英文短路径别放默认下载目录第一步是找解压工具。rar 格式优先用 WinRAR 或 7-Zip 处理不要拿 Windows 自带的“全部解压缩”去碰那个只认 zip。我习惯用 7-Zip 命令行解可写进自动部署脚本7z x cmake-3.10.0-win64-x64.rar -oC:\Tools参数说明x 表示解压并保留目录结构-o 后面直接跟目标目录注意 -o 和路径之间不能加空格。解压完成后会得到 C:\Tools\cmake-3.10.0-win64-x64里面的核心内容有两个bin 目录下放着 cmake.exe、cmake-gui.exe、ctest.exeshare 目录下是 CMake 内置模块和模板这些东西在 configure 阶段会用到所以整个目录不能只拷一个 exe 出来用。路径选择有讲究。C:\Tools 这类纯英文、无空格、层级浅的路径最省心。不要放 C:\Program Files 下面虽然 CMake 对带空格的路径也能处理但后续要是接 Ninja、接 Qt、接 vcvarsall.bat空格会显著提高报错概率。也别放中文用户名目录里3.10 的编码处理在中文路径下偶尔会有玄学问题这个后面避坑章节再展开。3.2 手动配置 PATHcmd 和 PowerShell 的两种写法解压只是把文件放到磁盘上要让命令行认得出 cmake得把 C:\Tools\cmake-3.10.0-win64-x64\bin 加进 PATH。常见做法是配置用户级环境变量这样不需要管理员权限也不会污染系统全局配置。cmd 下用 setx 写的做法setx PATH %PATH%;C:\Tools\cmake-3.10.0-win64-x64\binPowerShell 下推荐直接改用户级环境变量$oldPath [Environment]::GetEnvironmentVariable(Path, User) $newPath $oldPath ;C:\Tools\cmake-3.10.0-win64-x64\bin [Environment]::SetEnvironmentVariable(Path, $newPath, User)参数说明setx 的坑在于它会读取当前终端里的 PATH 快照写回注册表如果当前终端 PATH 已经被其他程序改得乱七八糟容易把旧值截断PowerShell 版本直接操作 User 级别的原始值更安全。注意 setx 有 1024 字符截断风险如果你的 PATH 已经很长调用前先 echo %PATH% 看看长度。修改完之后已经打开的 cmd 窗口不会自动生效必须新开一个终端。这一点很多人反复栽配置完 PATH 后在原窗口试 cmake --version结果还是“不是内部或外部命令”于是认为是安装包有问题。3.3 验证版本为什么 cmake --version 是第一个检查项新开 cmd 或 PowerShell 窗口后依次执行三条命令验证环境cmake --version where cmake cmake --help参数说明cmake --version 会输出版本号看到 3.10.0 就说明 exe 能跑where cmake 检查当前 PATH 里找到的 cmake 到底是哪一个防止机器里装了多个版本导致调错cmake --help 输出生成器列表和参数说明这能顺便验证 3.10 内置生成器是否正常加载。版本验证这一步看着简单但它是后面一切排错的前提。特别是机器里已经装了新版 CMake 的场景你费劲配置半天where cmake 才发现系统优先找到的是 C:\Program Files\CMake\bin老版本根本没参与构建。这种情况的处理办法是把 C:\Tools\cmake-3.10.0-win64-x64\bin 在 PATH 里的顺序提前到最前面或者干脆在构建脚本里写死 cmake 的绝对路径。3.4 CMake GUI 第一次打开连 VC 运行库都可能是障碍命令行能用之后再验证 GUI。cmake-3.10.0-win64-x64\bin\cmake-gui.exe 不依赖安装器但依赖 Microsoft Visual C 运行库。如果你那台机器是从零开始的内网环境双击 cmake-gui.exe 很可能直接弹“由于找不到 VCRUNTIME140.dll 无法继续执行”。这不是安装包坏了而是系统缺 VC 2015-2022 Redistributable x64。解决办法是找一台能上网的机器下载并安装 vc_redist.x64.exe然后离线拷到目标机器上装上。装完再打开 cmake-gui就能看到熟悉的界面了上方是 source 目录和 build 目录中间是配置选项区下方是 configure 和 generate 按钮。GUI 和命令行用的是同一个引擎差别只在你不必手敲参数。提示GUI 工具在首次 Configure 时会把你选的生成器缓存在 CMakeCache.txt 里。以后同一个 build 目录再用命令行 cmake .. 会自动沿用缓存里的生成器不需要重新指定 -G但前提是 cache 没有被删除。4. 用 3.10 跑通一个 Windows 最小构建从命令行到 Ninja环境配好之后找一个最小工程验证整个链路。这里用一个只有单个源文件的项目做示范从写 CMakeLists.txt 到生成、编译完整走一遍。这一步跑通就说明 cmake-3.10.0-win64-x64 里的核心模块没有因为解压路径、运行库或 PATH 问题产生残缺。4.1 最小 CMakeLists.txt 文件新建目录 D:\demo在里面放 main.cpp 和 CMakeLists.txtcmake_minimum_required(VERSION 3.10) project(demo LANGUAGES CXX) add_executable(demo main.cpp)#include iostream int main() { std::cout cmake 3.10 demo std::endl; return 0; }逻辑说明cmake_minimum_required(VERSION 3.10) 告诉 CMake 按 3.10 的策略处理兼容性问题也顺带排除了机器上更老版本运行时直接拒绝的情况。project(demo LANGUAGES CXX) 声明这是一个只用 C 的项目CMake 会由此决定去探针哪个编译器。add_executable(demo main.cpp) 把 main.cpp 编成 demo.exe。这个文件结构是所有 CMake 工程的地基。4.2 命令行配置生成生成器参数怎么选进入 D:\demo 目录后标准做法是创建 build 目录隔离源码和产物cmake -S D:\demo -B D:\demo\build -G Visual Studio 15 2017 -A x64参数说明-S 指定源码根目录-B 指定构建目录构建目录不存在时会自动创建。-G 后面是生成器名称引号不能省因为 Visual Studio 15 2017 里有空格。-A x64 是 3.8 引入的架构选项等价于老写法里把生成器写成 “Visual Studio 15 2017 Win64”。3.10 两种都支持优先用 -A x64语义更清晰。如果这台机器没装 VS2017而你想测试命令行流程可以换成 MinGW 工具链cmake -S D:\demo -B D:\demo\build -G MinGW Makefiles -DCMAKE_CXX_COMPILERg参数说明MinGW Makefiles 生成器需要 mingw32-make 和 g 都在 PATH 里DCMAKE_CXX_COMPILER 用来显式指定编译器。CMake 探针会去验证 g 能不能编译小型测试程序验证通过才会继续。这个路径适合装了 MinGW-w64 但没装 Visual Studio 的开发者。configure 完成后build 目录下会生成 CMakeCache.txt、CMakeFiles 目录和 .sln 工程文件。这时候再执行编译cmake --build D:\demo\build --config Release参数说明--build 是统一入口CMake 会读缓存里的生成器自己调用 MSBuild 或 make 完成编译。--config Release 只在多配置生成器VS下有意义对于单配置生成器MinGW Makefiles、Ninja构建类型在 configure 阶段用 -DCMAKE_BUILD_TYPE 指定。4.3 CMake GUISource/Build 路径和 Configure 按钮生成的缓存文件命令行跑通以后再用 cmake-gui 演示一遍。打开 cmake-gui在 Source 一栏填 D:\demo在 Build 一栏填 D:\demo\build_gui点 Configure第一次会弹出生成器选择框选 Visual Studio 15 2017架构选 x64然后 CMake 开始执行探针并生成缓存。这个过程中 GUI 底部的输出窗口会滚动显示编译器检测信息和命令行输出完全一致。Configure 之后点 Generate会生成 .sln 文件。这跟你用命令行 -S -B 的效果没有区别区别只在于 GUI 可以随时改选项比如想在 Release 和 Debug 之间切换在 GUI 里的 CMAKE_BUILD_TYPE 或 VS 多配置下拉框里改。对新手来说GUI 的最大价值是能看到每一轮配置到底卡在哪个模块上。顺便说一句很多人用 VSCode 配 CMake 开发VSCode 的 CMake Tools 插件只是调用系统里的 cmake最终行为仍然是这套流程。你给插件指定的 kit本质上就是指定 -G 生成器和编译器的组合。4.4 用 Ninja 提速ninja cmake 的组合怎么配VS 生成器会生成 .sln但增量编译速度一般。想要更快的本地构建常见做法是配 NinjaCMake 生成 build.ninja 文件Ninja 根据依赖关系并行执行编译。cmake-3.10.0-win64-x64 本身支持 Ninja 生成器但它不附带 ninja.exe需要另备一个放 PATH 里。假设 ninja.exe 在 C:\Tools\ninja配置步骤set PATHC:\Tools\ninja;%PATH% cmake -S D:\demo -B D:\demo\build_ninja -G Ninja -DCMAKE_BUILD_TYPERelease ninja -C D:\demo\build_ninja参数说明第一行把 ninja 目录临时加进当前终端 PATH第二行让 CMake 使用 Ninja 生成器CMAKE_BUILD_TYPE 指定 Release对应编译选项是 -O2第三行 ninja -C 是 Ninja 自己的编译命令效果等同 cmake --build build_ninja。Ninja 在增量编译上比 VS 生成器快不少因为它不用反复检查 .vcxproj 的项目依赖链。Ninja 配合 VS2017 的 cl.exe 时需要先激活 vcvarsall 环境否则 CMake 找不到编译器和 Windows SDK。这一步经常被忽略于是又出现编译器探针问题。call C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat x64参数说明vcvarsall.bat 是 VS 提供的环境初始化脚本它把 cl.exe、link.exe、Windows SDK 的 include/lib 路径全部注入当前终端。必须在同一个终端窗口里先执行它再执行 cmake。VS 生成器在 GUI 环境下会自动处理这部分Ninja 生成器不会因为 Ninja 本身不是 VS 的构件。5. 安装和使用的 5 个常见坑从“找不到编译器”到 Qt5Config.cmake 报错下面这些坑是我在 Windows 上给项目装 cmake-3.10.0-win64-x64 时反复踩过的。每一条都按“现象 → 原因 → 解决”写希望能让你少走弯路。5.1 cmake 不是内部或外部命令现象新开 cmd 窗口执行 cmake --version系统提示“cmake 不是内部或外部命令也不是可运行的程序或批处理文件”。原因只有三种可能。第一种是 PATH 变量里确实没加 bin 路径或者加的路径写错了比如写成了 C:\Tools\cmake-3.10.0-win64-x64 而不是其下的 bin。第二种是终端窗口没重开PATH 修改还在缓存里。第三种是 PATH 里同时有多个 CMake系统先找到了旧版本或损坏版本。解决先 echo %PATH% 看有没有 bin 路径再新开一个终端试再用 where cmake 看实际命中的是哪个文件。定位到具体是哪一层问题之后用 3.2 小节的 PowerShell 方式重新写一遍用户级 PATH然后重开终端。5.2 Visual Studio 2022 装好了3.10 却提示找不到生成器现象机器上装了最新的 Visual Studio 2022执行 cmake -S . -B build 时报错提示找不到可用的生成器或者 “Could not find a supported Visual Studio version”。原因cmake-3.10.0-win64-x64 的 VS 生成器只认识 VS2017 这一代的注册表项。VS2022 的安装信息对 3.10 来说是个黑匣子CMake 靠探测注册表里的 VsDevCmd.bat、vswhere 等机制来定位编译器老版本不认识新路径。解决要么换这台机器上的构建工具链安装 VS2017 Build Tools要么升级 CMake 到支持 VS2022 的版本。3.10 和 VS2022 之间没有可行的兼容参数别试图用 -G 字符串硬凑。如果你只是需要在同一台机器上用老 CMake 构建老项目装的 VS2017 和 VS2022 可以共存通过 vcvarsall.bat 的路径区分。5.3 编译器探针失败CMakeDetermineCompilerId 相关报错现象configure 阶段输出“Compiling the CXX compiler identification source file”之后直接报错错误信息里能看到 CMakeDetermineCompilerId.cmake 相关路径在 Linux 上常见的是 cmake error at /usr/share/cmake-4.2/modules/cmakedeterminecompilerid.cmake:9 这类报错Windows 上则表现为探针生成的临时 exe 无法运行。原因探针是 CMake 在 build 目录的临时子目录里生成一个极小程序并用检测到的编译器去编译运行。如果杀毒软件实时防护拦截了探针生成的临时 exe或者编译器路径、Windows SDK 环境没配对探针必然失败。解决先在 PowerShell 里执行 vcvarsall.bat 激活完整编译环境再重新 cmake同时把杀毒软件对 build 目录的实时扫描临时关掉。如果确认是杀软问题将 build 目录加入白名单。最后删掉 CMakeCache.txt 和 CMakeFiles 目录再 configure探针结果不会被旧缓存污染。5.4 Qt5Config.cmake 报错找不到 Qt5 组件现象项目里写了 find_package(Qt5 COMPONENTS Core Widgets)configure 时报错大意是“Could not find a package configuration file provided by Qt5”网上常出现的是 cmake error at c:/qt/qt5.9.4/5.9.4/msvc2017_64/lib/cmake/qt5/qt5config.cmake 这种具体路径的报错。原因CMake 的 find_package 依赖 CMAKE_PREFIX_PATH 去搜索 Qt 安装目录。如果你没把 Qt 的 msvc2017_64 路径告诉 CMake它根本不知道 Qt5Config.cmake 在哪。另一个原因是 Qt 库的编译器和当前生成器不匹配比如拿 Qt 的 msvc2017 库去配 MinGW即使找到了 Qt5Config.cmake探针也会在编译阶段失败。解决显式指定前缀路径正斜杠和反斜杠都行但我习惯用正斜杠避免转义问题cmake -S D:\demo -B D:\demo\build -G Visual Studio 15 2017 -A x64 -DCMAKE_PREFIX_PATHC:/Qt/Qt5.9.4/5.9.4/msvc2017_64参数说明CMAKE_PREFIX_PATH 告诉 CMake 到哪个根目录下去找库的 config.cmake。Qt5Config.cmake 的实际位置是 lib/cmake/Qt5 下的包配置CMake 会自动拼接查找。这一项加对之后Qt5 的 include、lib、dll 路径都会自动进入构建。5.5 中文路径导致 configure 失败玄学但真实的编码问题现象工程文件全在 D:\测试项目\demo 下cmake-gui 能正常打开但 configure 时报“无法打开文件”或“invalid escape sequence”错误信息有时还带着乱码。原因CMake 3.10 对 Windows 中文路径的处理不完善。它内部大部分字符串按 UTF-8 处理老版本又不做代码页转换中文字符在 NMake 或 MSBuild 调用环节里很容易变成乱码传给编译器。解决把源码、构建目录、Qt 路径、CMake 安装路径全部放到纯英文路径下。已经写在中文路径里的项目复制到 D:\demo 再构建别在 CMake 层面强改代码页太折腾且不保证有效。这是我目前见过的唯一“换路径就好”的 CMake 玄学问题——你可以在英文路径下多试几种写法中文路径则每次都翻车。6. 再进一步把 3.10 配给 Qt 5.9.4 MSVC2017 的完整参数和验证方法最后给你一套我在实际项目中用过的完整参数组合目标是用 cmake-3.10.0-win64-x64 构建一个依赖 Qt 5.9.4 的 64 位桌面程序。这套组合适合老项目离线迁移也适合新项目主动锁定老工具链。先写好 CMakeLists.txt 的顶层组织。多模块项目常见做法是顶层文件只做全局声明和子目录添加不写具体源文件cmake_minimum_required(VERSION 3.10) project(myapp LANGUAGES CXX) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTORCC ON) find_package(Qt5 COMPONENTS Core Widgets REQUIRED) add_subdirectory(src) target_link_libraries(myapp PRIVATE Qt5::Core Qt5::Widgets)逻辑说明set(CMAKE_AUTOMOC ON) 让 CMake 对含 Q_OBJECT 的头文件自动运行 moc这是 Qt 项目必需的一步手写 moc 命令会又累又容易错。find_package(Qt5...) 里的 REQUIRED 表示找不到就中断 configure避免生成一个注定编译失败的工程。配置构建目录cmake -S . -B build -G Visual Studio 15 2017 -A x64 -DCMAKE_PREFIX_PATHC:/Qt/Qt5.9.4/5.9.4/msvc2017_64 -DCMAKE_BUILD_TYPERelease参数说明这套参数里-G 锁定生成器-A 锁定架构CMAKE_PREFIX_PATH 指向 Qt 的 msvc2017_64 目录。VS 生成器下 CMAKE_BUILD_TYPE 实际不参与编译选项真正的 Release/Debug 由 VS 里的 config 切换决定但写上无妨有些脚本会读取它做条件判断。验证方法分三步。第一步看 configure 输出末尾有没有 “Configuring done” 和 “Generating done”第二步打开 build 目录下的 .sln确认 Qt5 的引用和 moc 生成文件都在第三步直接编译 exe运行起来确认 Qt 的 dll 能找到。Qt 的 dll 需要拷贝到 exe 目录或者把 C:/Qt/Qt5.9.4/5.9.4/msvc2017_64/bin 加到 PATH。我的个人习惯是每在一台机器上装好这类离线安装包就在 C:\Tools 下建一个 README.txt把 CMake 版本、对应 VS 版本、Qt 路径、Ninja 路径、谁装的、装给哪个项目用全部写进去。半年后再回来看看这个 README 就是你最大的后悔药——不然你根本记不清这台机器上的 3.10 是从哪拷来的、当时为什么不用 3.20。希望帮到你。本文还有配套的精品资源点击获取