尧图网站建设 
简介CMake 3.10.0 Windows 64位安装包面向Windows平台开发者用于管理跨平台项目的构建流程。它依据CMakeLists.txt中的指令将目标文件、源文件、依赖库和编译选项转换为Makefile、Visual Studio解决方案或Ninja工程免去手工维护构建脚本的繁琐。压缩包体积约18.61MB包含可直接运行的安装程序安装后即可通过命令行或cmake-gui配置项目已有1676人学习/下载。通过实际操作读者能熟悉PROJECT、ADD_EXECUTABLE、ADD_LIBRARY、FIND_PACKAGE、TARGET_LINK_LIBRARIES等常用命令并借助INCLUDE_DIRECTORIES与SET变量管理头文件路径和构建参数ADD_SUBDIRECTORY可引入子目录MESSAGE用于输出调试信息理解option选项、工具链文件以及生成器对IDE和平台的适配机制。3.10.0版本在模块支持和构建优化上有所改进对Windows 64位用户尤为实用可作为日常构建管理的基础工具。1. cmake-3.10.0-win64-x64.rar 安装包旧项目里最常出现的那个 cmake 安装包如果你维护过 Qt 5.9.4、VS2017 或者 OpenCV 3.4.x 这一代的老工程大概率在某个“cmake 下载”“cmake 安装包”的网页里见过这个名字cmake-3.10.0-win64-x64.rar。它不是官方分发形式官方发的是 zip 和 msi但国内不少网盘和内部资料库会把它压成 rar 再传解压出来就是一个绿色版 CMake。这个包解决的是很具体的问题不需要管理员权限、不写注册表、解压就能跑而且版本正好卡在 2017 年到 2019 年那批 Windows C 项目最需要的兼容点上。这篇笔记面向正维护老代码、被新版 CMake 策略变更折腾过、或者想知道这个包到底能不能用的从业者我会把手上的解压路径、环境变量、构建命令和踩过的坑一次讲完。2. 装之前先看版本关系CMake 3.10.0 配哪代编译器和 Qt2.1 CMake 的版本号逻辑3.10.0 不代表“3 代”而是 2017 年的一道分水岭先纠正一个常见误会CMake 3.10.0 不是“第三代”它的版本号意思是主版本 3、次版本 10、补丁版本 0发布于 2017 年 11 月。这个版本在 CMake 历史上有一个特殊位置它是第一个把 VS2017 支持放到首位、并且对 Qt 5.9/Qt 5.10 的 find_package 检测做得比较成熟的版本。3.10 之后CMake 也补进去了 target_sources、cmake --build 的 target 指定等今天常用的语法所以老工程里很多 CMakeLists.txt 写的 min version 就是 3.10。版本选型时要抓住一个判断你手里的项目最低要求是多少就用那个版本区间里最靠谱的一个。CMake 是向后兼容做得非常好的工具但“向后兼容”不等于“行为和旧版一模一样”。CMake 引入 policy 机制来控制行为变化从 3.10 到新版之间CMP 编号积压了上百条旧工程在新 CMake 上跑经常出现“configure 不报错、编译出来的东西行为变了”的情况这正是很多人最终装回 cmake-3.10.0-win64-x64.rar 的原因。在线文档里能查到 3.10 的 release notes里面明确写了支持 Visual Studio 2017、Ninja、Xcode 9以及 Qt 5.10。但 release notes 不会告诉你的是3.10 时代的 FindQt4 / FindQt5 模块找的是 Qt5Config.cmake而不是后来 Qt6 那套。这意味着如果你维护的是 Qt 5.9.4 MSVC 2017 这种组合3.10.0 是最舒服的档位再高版本也能用但没必要为了追新去承担策略变动的风险。2.2 编译器代际对照表3.10 到底能认哪几个 GeneneratorCMake 在 Windows 上选编译器依赖“生成器”概念-G 参数后面的字符串直接决定它能驱动哪一套构建系统。下表是你拿到 3.10.0 后最可能用到的生成器组合CMake 3.10 支持的生成器Win64 平台字符串适合场景Visual Studio 14 2015Win64VS2015 老工程Qt 5.9 msvc2015_64Visual Studio 15 2017Win64VS2017 工程Qt 5.9 msvc2017_64Ninja无单一平台想绕开 VS 工程文件、直接用 cl.exe 命令行MinGW Makefiles无装了 mingw-w64、不用 MSVC 的情况NMake Makefiles无在 VS 命令行里用 nmake 构建注意一个关键词Visual Studio 16 2019 在这个表里不存在。CMake 官方从 3.14 才开始认得 VS2019 生成器3.10 遇到它只会报“Could not create generator‘Visual Studio 16 2019’”。所以如果你的电脑装的是 VS2019 或 VS2022又想保留 3.10最现实的做法是安装 VS2017 的 BuildTools 组件或者老老实实升级 CMake。我见过不少人把 VS2019 离线安装包装完然后拿 CMake 3.10 去配置折腾半小时只得到一行报错这属于版本代际没对上。2.3 为什么那么多人不升级新版的坑和老版的边界说句公道话新版本 CMake 不是不好而是它默认的最低策略和工具链假设变了。比如新版 CMake 在 Ubuntu 上偶尔也会出现网上常刷的那个“cmake error at /usr/share/cmake-4.2/modules/cmakedeterminecompilerid.cmake:9”报错本质是编译器探测环节出了问题。这类报错跟版本新旧没有必然关系但能说明一个事实CMake 从来不是一个“装了就能编”的工具它只是把编译器探测、语法检查、目录管理这些问题从你手上接过去而出了问题你照样要去翻日志。旧版本 3.10.0 的边界在于它完善支持的是 2017 年那一代工具链C17 标准特性它能认但不要指望它在 CUDA 新版本、VS2022、Qt6 这些新东西上好好工作。所以选择 cmake-3.10.0-win64-x64.rar 的人通常不是不知道新版存在而是手上项目对“某年某版本的工具链”有硬性耦合。比如 Qt 5.9.4 的 msvc2017_64 预编译库它在编译时假设 CMake 至少能找到 VS2017 的编译器而新版 CMake 虽然也找得到但会引入更激进的链接器标志。老项目一旦换了 CMake 大版本哪怕 configure 成功链接阶段也可能冒出来一整屏 LNK 开头的报错这玩意儿根本不像语法错误那么好定位。我的建议是除非你有明确的理由要使用新 CMake 特性否则老工程就让它的 CMake 留在老版本上不要顺手“升级一下工具链”给自己找事。3. 把 rar 变成可用的 cmake解压、PATH、三个验证命令3.1 这个包不需要“安装”解压即用与一个临时环境脚本cmake-3.10.0-win64-x64.rar 解压之后你会得到一个目录里面是 bin、share、doc 三个子目录。bin 下放着 cmake.exe、cmake-gui.exe、ctest.exe、cpack.exe。ctest 和 cpack 是测试和打包组件很多人在老项目里只看得到 cmake.exe其实这两个后面也能用上。常见做法是用 WinRAR 或 7-Zip 解压到 D:\tools形成 D:\tools\cmake-3.10.0-win64-x64\bin\cmake.exe。然后问题来了要不要把 bin 目录加进系统 PATH我一般不建议用 setx 直接改全局 PATH因为 setx 会把整个 PATH 重新写一遍超过 1024 字符会被截断机器重启之后一堆命令失效这是 Windows 上最著名的环境变量翻车现场之一。更稳的做法是建一个临时的环境脚本在你需要编译的那个命令行窗口里先执行它echo off set CMAKE_HOMED:\tools\cmake-3.10.0-win64-x64 set PATH%CMAKE_HOME%\bin;%PATH% cmake --version这段脚本的逻辑很直白先定义 CMAKE_HOME 指到解压根目录然后把它的 bin 目录插到 PATH 最前面再执行 cmake --version 确认生效。%PATH% 前面的部分保证在同一个窗口里后续所有命令优先找到的是我们刚解压的 3.10.0而不是系统里可能存在的其他版本。如果你不喜欢每次开窗口都敲一遍可以把这段存成 cmake_env.bat放在 D:\tools 下以后编译前先 call 一下就行。3.2 三行命令验证“装好了”版本号、路径、能力列表解压和 PATH 做完别急着去配置工程先跑三个验证命令。第一个是 where cmake看当前命令行会调用到哪个路径下的 cmake.exe第二个是 cmake --version确认版本号是 3.10.x第三个是 cmake -E capabilities输出一个 JSON 表示这个版本支持的能力集合。我贴一组典型操作where cmake cmake --version cmake -E capabilities第一个命令解决的是“我明明装了为什么调用的不是我装的那个”的经典问题。如果你机器里还装过其他 CMakewhere 会按 PATH 顺序全部列出来排在最上面的才是实际生效的那个。第二个命令确认版本输出类似 cmake version 3.10.0。第三个命令是很多老手会忽略的它输出的 JSON 里有 generator 列表、文件 API 支持情况、server 模式是否可用。3.10.0 的 capabilities 里 generator 列表会包含 Visual Studio 15 2017 和 Ninja看到这些说明这个包本身是完整的后续报错可以放心去查编译器或工程文件而不是怀疑安装包损坏。如果 where cmake 找不到任何结果回到 3.1 的脚本确认解压路径是不是真的存在。最常见的原因是解压时把外层目录又套了一层比如解压成 D:\tools\cmake-3.10.0-win64-x64\cmake-3.10.0-win64-x64\bin脚本里写的路径就对不上了。3.3 cmake-gui 在这版里够用什么时候别跟风命令行3.10.0 的 bin 目录里有 cmake-gui.exe它不是摆设。很多人一上来就追求全命令行操作其实在处理 Qt 的 CMAKE_PREFIX_PATH、OpenCV 的模块开关这类多路径、多开关场景时GUI 反而更直观。cmake-gui 打开后上面填源码目录下面填 build 目录点 Configure 第一次会弹生成器选择框选完再点 Generate。3.10 的 GUI 没有后来版本的自动搜索工具链提示但基本功能都在Add Entry 用来加 CMAKE_PREFIX_PATH 这种缓存变量Grouped 视图可以按 CMAKE、Qt、OpenCV 分类看变量比命令行敲 -D 一个个传肉眼核对舒服。我的习惯是第一次配置用 GUI因为要试探很多变量确认全部参数后把 GUI 里生成的 CMakeCache.txt 保留后面全部用命令行 cmake --build . 做增量构建。GUI 生成的缓存是纯文本你用编辑器打开也能看到每个 -D 参数的真实值排查问题比命令行回显更清楚。3.10 的 GUI 不会有新版本那种“首次配置自动探测 Ninja”的便利但别嫌它老它处理老工程的场景真够用。4. 用 CMake 3.10.0 构建一个最小 Windows C 工程可复制的四条命令4.1 先把 MSVC 环境拉起来vcvars64 比你想象的重要在 Windows 上用 CMake 配 Visual Studio 2017 的人最容易犯的错误是直接打开普通 cmd然后执行 cmake -G Visual Studio 15 2017 Win64。这个操作在多数机器上能通过配置阶段因为 VS 生成器是等编译时才调用 cl.exe 的而 cl 的环境变量没加载的话会在编译阶段报“找不到 cl.exe”或者直接编译失败。还有更进一步的情况是它能找到 cl但找不到 link.exe、rc.exe那些报错更隐蔽。正确做法是先加载 VS 开发环境。VS2017 里对应的是 vcvars64.bat通常藏在安装目录的 VC\Auxiliary\Build 下。Professional 版、Enterprise 版、Community 版路径前缀会不同BuildTools 单独安装又在另一个目录。典型调用是这样call C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\Build\vcvars64.bat注意是 call 不是直接执行因为 vcvars64.bat 里设置了大量临时环境变量直接执行是开个子进程设置完就没了不会影响当前命令行窗口。加载之后再执行 cl 或 where cl 就能看到 MSVC 编译器路径。CMake 在你用 VS 生成器时其实是靠自身寻找工具链不需要 vcvars但很多老项目会额外配置外部依赖和自定义命令这些命令里如果用了 cl、mt、rc 之类的工具没有 vcvars 就会失败。所以我建议养成习惯所有 CMake 命令都在 vcvars64 之后执行。如果你不想装完整 VS2017只想要编译器也可以考虑 mingw-w64 安装包加 MinGW Makefiles 生成器的组合。写法是 cmake -G MinGW Makefiles -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERg。但这套组合跟 Qt 5.9.4 的 msvc2017_64 预编译库不匹配链接 Qt 库时会因为符号约定不同翻车。选工具链之前先确认依赖库本身的编译约定这是我在老项目上最能省时间的经验。4.2 最小工程模板CMakeLists.txt 与四条构建命令先看一个我能直接抄的工程模板包含一个 main.cpp 和一个 CMakeLists.txt// main.cpp #include iostream int main() { std::cout legacy cmake ok std::endl; return 0; }cmake_minimum_required(VERSION 3.10) project(legacy_demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(legacy_demo main.cpp)这个 CMakeLists.txt 的写法体现了 3.10 时代的规范。cmake_minimum_required 放在第一行表示这个工程最低需要 3.10如果 CMake 版本低于它会直接报错project 指定工程名和语言LANGUAGES CXX 让 CMake 只探测 C 编译器不至于多花时间去探测 C 和 Fortran。CMAKE_CXX_STANDARD 设为 14 是因为 3.10 已经能很好处理 C14如果设 17老版本的某些 MSVC 版本会陷入部分标准支持不完整的尴尬。构建命令只有四条mkdir build cd build cmake -G Visual Studio 15 2017 Win64 .. cmake --build . --config Release第一行建 build 目录第二行切进去这两步的作用是把源码目录和构建目录分离。CMake 时代不应该在源码目录里直接产出临时文件否则哪天你想换生成器或者清理重编源码目录会被缓存文件污染得很难看。第三行是关键-G 指定生成器后面的 .. 是源码目录位置。因为我们在 build 子目录里.. 指回工程的根目录。第四行是老版本里最好用的命令之一cmake --build 会读取当前目录里已经生成的构建系统并驱动编译不需要再单独调 msbuild 或者 nmake。用 CMake 之后你可以完全不用手写 MakefileCMakeLists.txt 本身就是跨构建系统的描述文件。网上关于“makefile和cmake的区别”讨论很多落到这个版本上的直观区别就是你维护的是 CMakeLists.txt改一次语法就能同时生成 VS 工程、Ninja 脚本或 Makefile。这也是为何老项目宁可守着 3.10 也不转回 Makefile 的原因。4.3 必设参数CMAKE_PREFIX_PATH、CMAKE_BUILD_TYPE、CMAKE_INSTALL_PREFIX上面四条命令能跑通不带动两个参数的场景但真实老项目几乎没有不带依赖的。最常用的参数是 CMAKE_PREFIX_PATH它告诉 CMake 去哪找 SDK 的配置文件。拿 Qt 5.9.4 举例很多人把 Qt 装到 D:\Qt\Qt5.9.4然后在 CMake 里写 find_package(Qt5 COMPONENTS Core Widgets)结果配置时找不到原因就是 CMake 默认搜索路径里根本没有 D:\Qt 这一项。需要手动加cmake -G Visual Studio 15 2017 Win64 -DCMAKE_PREFIX_PATHD:/Qt/Qt5.9.4/5.9.4/msvc2017_64 ..这个参数的值不是 Qt 的安装根目录而是 Qt 库目录所在的那一层它下面需要能找到 lib\cmake\Qt5\Qt5Config.cmake。如果你传错了层级比如传成 D:/Qt/Qt5.9.4Qt 的配置文件找得到但版本探测多半会对不上。另一个常见参数是 CMAKE_BUILD_TYPE只对单配置生成器有效像 Ninja、MinGW Makefiles你需要写 -DCMAKE_BUILD_TYPERelease但对 Visual Studio 生成器构建类型是在构建时通过 --config Release 指定的写 CMAKE_BUILD_TYPE 不会报错但也没作用这就是参数在两种生成器下的行为差异。CMAKE_INSTALL_PREFIX 是另一个容易踩的参数。3.10 还没引入 cmake --install 命令那是 3.15 才有所以在 3.10 里安装是执行cmake --build . --config Release --target install默认的安装路径在 Windows 上是 C:\Program Files\legacy_demo如果你不想把文件装到系统盘就在配置阶段加 -DCMAKE_INSTALL_PREFIXD:/deploy/legacy_demo。注意 3.10 的这个参数必须在配置阶段传后期改 CMakeCache.txt 虽然也有用但很多子目录的 install 规则是配置时就展开的改晚了会导致一部分文件装错位置。这属于老版本特有的边界坑新版 CMake 也不会帮你兜着。5. 避坑记录cmake-3.10.0 在 Windows 上我踩过的 5 个坑5.1 现象CMD 提示“cmake 不是内部或外部命令”但明明解压好了原因rar 解压后bin 目录没进 PATH或者进了系统 PATH 但当前命令行窗口是在修改 PATH 之前打开的。Windows 的环境变量是在进程启动时读取的已经打开的 cmd 不会自动刷新。解决打开新 cmd或者执行 3.1 里的 cmake_env.bat。如果开新窗口还不行用 where cmake 查一下系统 PATH 里是否真的包含那个 bin 目录。另外一个高频原因解压时多套了一层目录你 PATH 里写的是 D:\tools\cmake-3.10.0-win64-x64\bin但实际解压路径是 D:\tools\cmake-3.10.0-win64-x64\cmake-3.10.0-win64-x64\bin这种路径嵌套在网盘压缩包里特别常见解压后务必先看一眼目录结构。5.2 现象cmake --version 显示的不是 3.10.0而是机器上的其他版本原因系统里之前装过 CMake 3.16、3.20 之类且它的路径排在当前 PATH 的前面。where cmake 会把所有候选路径列出来Nature 顺序决定优先使用谁。解决执行 where cmake 看清楚临时方案是直接用绝对路径调 D:\tools\cmake-3.10.0-win64-x64\bin\cmake.exe长期方案是把 3.10 的 bin 目录放到 PATH 最前面或者用 cmake_env.bat 在窗口内前置。我见过有人因此把新版 CMake 卸载了事后发现另一个项目必须用新版这就很麻烦。正确做法是让两个版本共存用脚本切换而不是粗暴卸载。5.3 现象配置时报错“could not find a package configuration file provided by Qt5”后面还跟着 qt5config.cmake 的路径原因CMake 在 CMAKE_PREFIX_PATH 指定的路径里没有找到 Qt5Config.cmake。常见的是 CMAKE_PREFIX_PATH 没有传或者传到了 Qt 安装根目录而正确指向应该是 msvc2017_64 那一层。也有更隐蔽的原因Qt 5.9.4 的 msvc2017_64 库要求使用 VS2017 工具链如果你用的是 MinGW 或 VS2015find_package 在解析 Qt5Config.cmake 内部依赖时会失败报错信息可能五花八门比如找不到 Qt5Core.dll 的导入库。解决先确认 CMakeCache.txt 里的 CMAKE_PREFIX_PATH 值再确认编译器生成器是 Visual Studio 15 2017 Win64最后确认你找的 Qt 目录名字是 msvc2017_64 而不是 msvc2015_64。对于多模块工程顶层 CMakeLists.txt 只放 add_subdirectory 和一个全局 find_package 就够Qt 组件拆到各自模块里找不然每个子目录都 find 一遍 Qt5配置阶段会慢得让人怀疑人生。5.4 现象配置时报编译器识别失败CMakeError.log 里写“The CXX compiler identification is unknown”原因这在 Windows 上八成是你没加载 vcvars64CMake 去探测 cl.exe 时找不到编译器在 Linux 上也有变体网上常见那个“cmake error at /usr/share/cmake-4.2/modules/cmakedeterminecompilerid.cmake:9”其实就是编译器探测失败的一种表现指向的是新版 CMake 在探测 C 编译器时连测试程序都编译不过。解决Windows 上先执行 4.1 的 vcvars64 调用再重新配置Linux 上检查 g 是否安装完整、gcc 和 g 版本是否一致。还有一个 Windows 特有的解决关键CMake 在探测失败后会把详细错误写进 build 目录下的 CMakeFiles\CMakeError.log这个文件里真的能看到 cl.exe 被调用时的完整命令行和输出。我建议每次碰到“unknown”第一反应不是重装 CMake而是打开这个日志找原因它往往比你在网上搜报错更快。5.5 现象装了 VS2019 或 VS2022用 3.10 配置时报“Could not create generator‘Visual Studio 16 2019’”原因CMake 3.10 本身不认识 2019 生成器。VS2019 用的是 Visual Studio 16 2019CMake 3.14 才开始正式支持3.10 不在支持范围。这不是安装包问题是版本代际不匹配。解决如果项目依赖必须锁 CMake 3.10解决方案是安装 VS2017 BuildTools配置时继续用 Visual Studio 15 2017 生成器如果项目可以接受新 CMake就换装 3.14 以上版本。还有一条中间路线用 VS2019 安装包的 MSVC 工具链配合 Ninja 生成器手动指定 CMAKE_C_COMPILER 为 VS2019 的 cl.exe 路径但这么做等于绕开了 CMake 的生成器保护逻辑部分 CMake 自定义命令仍可能因为找不到 VS 环境而失败。我一般不推荐这种玩法除非你对工具链加载原理已经很清楚。6. 让旧版 CMake 在机器上和新版共存工具链切换与升级界限6.1 快速切换脚本一个 cmake_env.bat 解决版本打架在同一台机器上同时保留 CMake 3.10.0 和 CMake 3.20 是完全可行的重点在于不要让它们同时出现在同一个命令行窗口的 PATH 的前缀部分。我把 3.1 的脚本扩展成双版本切换版echo off set CMAKE310_HOMED:\tools\cmake-3.10.0-win64-x64 set CMAKE_NEW_HOMED:\tools\cmake-3.20.0-win64-x64 :select echo 1 - CMake 3.10.0 echo 2 - CMake 3.20.0 set /p verchoose: if %ver%1 set CMAKE_HOME%CMAKE310_HOME% if %ver%2 set CMAKE_HOME%CMAKE_NEW_HOME% set PATH%CMAKE_HOME%\bin;%PATH% cmake --version这个脚本在你需要切版本时直接选择数字即可省去反复修改系统环境变量的操作。逻辑上它只把指定版本的 bin 目录临时插到 PATH 前缀不影响全局设置也不会把系统 PATH 写坏。配合 VSCode 的 CMake Tools 时如果你的工作区需要指定老版本可以在 .vscode/settings.json 里写{ cmake.cmakePath: D:\\tools\\cmake-3.10.0-win64-x64\\bin\\cmake.exe }这样 VSCode 里调用的 CMake 就是 3.10.0调试源代码时底层走的还是你指定的编译器。新版 CMake Tools 的很多功能依赖新 CMake 的文件 API3.10 支持的文件 API 版本比较早预设CMakePresets.json功能不可用但基本的 configure、build、debug 流程没有影响还算顺手。6.2 升级界限表什么情况必须告别 3.10.0给你一张我常用的判断表照着对照项目情况即可继续留在 3.10.0必须升级 CMakeQt 5.9.x / Qt 5.10.x 项目Qt6 或新版本 Qt 的跨平台工程VS2017 / VS2015VS2019 / VS2022 生成器需求C14 及以下标准需要 C20/23 的编译特性支持OpenCV 3.4.x 源码构建CUDA 新版本、新版 OpenCV现有 CMakeLists.txt 最低版本 3.10想用 cmake --install、CMakePresets这里最容易被忽视的是CMake 3.10 本身也能构建 C17 项目但它不会帮你做太严格的标准检查老版本在生成 VS 工程时的“/std:clatest”标志处理方式和新版不同如果工程里用了较新的标准库头文件可能在新版上能编过、在 3.10 上报一堆语法错误。这时候要分清是项目问题还是 CMake 版本问题我的判断标准是先看编译日志里是不是全部报 STL 头文件内部的错误如果是基本可以断定是工具链代际太老别死守老版本。最后说一句我自己的教训那一次我把一个 Qt 5.9 的老项目从 CMake 3.10 升到了 3.20configure 一次通过心里还挺高兴结果链接时出现十几个 LNK2019查了整整一个下午最后发现是 CMake 新策略默认改变了隐式链接 Qt 插件的方式。从那以后老项目换 CMake 大版本我必做的一步是先读一遍 release notes 里带 CMP 标记的变更再决定要不要升。这个习惯帮我躲过了后面好几次同类翻车。这个 cmake-3.10.0-win64-x64.rar 不是性能最优、不是功能最全但对特定一代工程就是合适的工具。按你自己项目的依赖代际做选择别被“越新越好”带跑偏。希望帮到你。本文还有配套的精品资源点击获取 CMake 3.10 安装包实战：老项目配置与避坑指南
简介CMake 3.10.0 Windows 64位安装包面向Windows平台开发者用于管理跨平台项目的构建流程。它依据CMakeLists.txt中的指令将目标文件、源文件、依赖库和编译选项转换为Makefile、Visual Studio解决方案或Ninja工程免去手工维护构建脚本的繁琐。压缩包体积约18.61MB包含可直接运行的安装程序安装后即可通过命令行或cmake-gui配置项目已有1676人学习/下载。通过实际操作读者能熟悉PROJECT、ADD_EXECUTABLE、ADD_LIBRARY、FIND_PACKAGE、TARGET_LINK_LIBRARIES等常用命令并借助INCLUDE_DIRECTORIES与SET变量管理头文件路径和构建参数ADD_SUBDIRECTORY可引入子目录MESSAGE用于输出调试信息理解option选项、工具链文件以及生成器对IDE和平台的适配机制。3.10.0版本在模块支持和构建优化上有所改进对Windows 64位用户尤为实用可作为日常构建管理的基础工具。1. cmake-3.10.0-win64-x64.rar 安装包旧项目里最常出现的那个 cmake 安装包如果你维护过 Qt 5.9.4、VS2017 或者 OpenCV 3.4.x 这一代的老工程大概率在某个“cmake 下载”“cmake 安装包”的网页里见过这个名字cmake-3.10.0-win64-x64.rar。它不是官方分发形式官方发的是 zip 和 msi但国内不少网盘和内部资料库会把它压成 rar 再传解压出来就是一个绿色版 CMake。这个包解决的是很具体的问题不需要管理员权限、不写注册表、解压就能跑而且版本正好卡在 2017 年到 2019 年那批 Windows C 项目最需要的兼容点上。这篇笔记面向正维护老代码、被新版 CMake 策略变更折腾过、或者想知道这个包到底能不能用的从业者我会把手上的解压路径、环境变量、构建命令和踩过的坑一次讲完。2. 装之前先看版本关系CMake 3.10.0 配哪代编译器和 Qt2.1 CMake 的版本号逻辑3.10.0 不代表“3 代”而是 2017 年的一道分水岭先纠正一个常见误会CMake 3.10.0 不是“第三代”它的版本号意思是主版本 3、次版本 10、补丁版本 0发布于 2017 年 11 月。这个版本在 CMake 历史上有一个特殊位置它是第一个把 VS2017 支持放到首位、并且对 Qt 5.9/Qt 5.10 的 find_package 检测做得比较成熟的版本。3.10 之后CMake 也补进去了 target_sources、cmake --build 的 target 指定等今天常用的语法所以老工程里很多 CMakeLists.txt 写的 min version 就是 3.10。版本选型时要抓住一个判断你手里的项目最低要求是多少就用那个版本区间里最靠谱的一个。CMake 是向后兼容做得非常好的工具但“向后兼容”不等于“行为和旧版一模一样”。CMake 引入 policy 机制来控制行为变化从 3.10 到新版之间CMP 编号积压了上百条旧工程在新 CMake 上跑经常出现“configure 不报错、编译出来的东西行为变了”的情况这正是很多人最终装回 cmake-3.10.0-win64-x64.rar 的原因。在线文档里能查到 3.10 的 release notes里面明确写了支持 Visual Studio 2017、Ninja、Xcode 9以及 Qt 5.10。但 release notes 不会告诉你的是3.10 时代的 FindQt4 / FindQt5 模块找的是 Qt5Config.cmake而不是后来 Qt6 那套。这意味着如果你维护的是 Qt 5.9.4 MSVC 2017 这种组合3.10.0 是最舒服的档位再高版本也能用但没必要为了追新去承担策略变动的风险。2.2 编译器代际对照表3.10 到底能认哪几个 GeneneratorCMake 在 Windows 上选编译器依赖“生成器”概念-G 参数后面的字符串直接决定它能驱动哪一套构建系统。下表是你拿到 3.10.0 后最可能用到的生成器组合CMake 3.10 支持的生成器Win64 平台字符串适合场景Visual Studio 14 2015Win64VS2015 老工程Qt 5.9 msvc2015_64Visual Studio 15 2017Win64VS2017 工程Qt 5.9 msvc2017_64Ninja无单一平台想绕开 VS 工程文件、直接用 cl.exe 命令行MinGW Makefiles无装了 mingw-w64、不用 MSVC 的情况NMake Makefiles无在 VS 命令行里用 nmake 构建注意一个关键词Visual Studio 16 2019 在这个表里不存在。CMake 官方从 3.14 才开始认得 VS2019 生成器3.10 遇到它只会报“Could not create generator‘Visual Studio 16 2019’”。所以如果你的电脑装的是 VS2019 或 VS2022又想保留 3.10最现实的做法是安装 VS2017 的 BuildTools 组件或者老老实实升级 CMake。我见过不少人把 VS2019 离线安装包装完然后拿 CMake 3.10 去配置折腾半小时只得到一行报错这属于版本代际没对上。2.3 为什么那么多人不升级新版的坑和老版的边界说句公道话新版本 CMake 不是不好而是它默认的最低策略和工具链假设变了。比如新版 CMake 在 Ubuntu 上偶尔也会出现网上常刷的那个“cmake error at /usr/share/cmake-4.2/modules/cmakedeterminecompilerid.cmake:9”报错本质是编译器探测环节出了问题。这类报错跟版本新旧没有必然关系但能说明一个事实CMake 从来不是一个“装了就能编”的工具它只是把编译器探测、语法检查、目录管理这些问题从你手上接过去而出了问题你照样要去翻日志。旧版本 3.10.0 的边界在于它完善支持的是 2017 年那一代工具链C17 标准特性它能认但不要指望它在 CUDA 新版本、VS2022、Qt6 这些新东西上好好工作。所以选择 cmake-3.10.0-win64-x64.rar 的人通常不是不知道新版存在而是手上项目对“某年某版本的工具链”有硬性耦合。比如 Qt 5.9.4 的 msvc2017_64 预编译库它在编译时假设 CMake 至少能找到 VS2017 的编译器而新版 CMake 虽然也找得到但会引入更激进的链接器标志。老项目一旦换了 CMake 大版本哪怕 configure 成功链接阶段也可能冒出来一整屏 LNK 开头的报错这玩意儿根本不像语法错误那么好定位。我的建议是除非你有明确的理由要使用新 CMake 特性否则老工程就让它的 CMake 留在老版本上不要顺手“升级一下工具链”给自己找事。3. 把 rar 变成可用的 cmake解压、PATH、三个验证命令3.1 这个包不需要“安装”解压即用与一个临时环境脚本cmake-3.10.0-win64-x64.rar 解压之后你会得到一个目录里面是 bin、share、doc 三个子目录。bin 下放着 cmake.exe、cmake-gui.exe、ctest.exe、cpack.exe。ctest 和 cpack 是测试和打包组件很多人在老项目里只看得到 cmake.exe其实这两个后面也能用上。常见做法是用 WinRAR 或 7-Zip 解压到 D:\tools形成 D:\tools\cmake-3.10.0-win64-x64\bin\cmake.exe。然后问题来了要不要把 bin 目录加进系统 PATH我一般不建议用 setx 直接改全局 PATH因为 setx 会把整个 PATH 重新写一遍超过 1024 字符会被截断机器重启之后一堆命令失效这是 Windows 上最著名的环境变量翻车现场之一。更稳的做法是建一个临时的环境脚本在你需要编译的那个命令行窗口里先执行它echo off set CMAKE_HOMED:\tools\cmake-3.10.0-win64-x64 set PATH%CMAKE_HOME%\bin;%PATH% cmake --version这段脚本的逻辑很直白先定义 CMAKE_HOME 指到解压根目录然后把它的 bin 目录插到 PATH 最前面再执行 cmake --version 确认生效。%PATH% 前面的部分保证在同一个窗口里后续所有命令优先找到的是我们刚解压的 3.10.0而不是系统里可能存在的其他版本。如果你不喜欢每次开窗口都敲一遍可以把这段存成 cmake_env.bat放在 D:\tools 下以后编译前先 call 一下就行。3.2 三行命令验证“装好了”版本号、路径、能力列表解压和 PATH 做完别急着去配置工程先跑三个验证命令。第一个是 where cmake看当前命令行会调用到哪个路径下的 cmake.exe第二个是 cmake --version确认版本号是 3.10.x第三个是 cmake -E capabilities输出一个 JSON 表示这个版本支持的能力集合。我贴一组典型操作where cmake cmake --version cmake -E capabilities第一个命令解决的是“我明明装了为什么调用的不是我装的那个”的经典问题。如果你机器里还装过其他 CMakewhere 会按 PATH 顺序全部列出来排在最上面的才是实际生效的那个。第二个命令确认版本输出类似 cmake version 3.10.0。第三个命令是很多老手会忽略的它输出的 JSON 里有 generator 列表、文件 API 支持情况、server 模式是否可用。3.10.0 的 capabilities 里 generator 列表会包含 Visual Studio 15 2017 和 Ninja看到这些说明这个包本身是完整的后续报错可以放心去查编译器或工程文件而不是怀疑安装包损坏。如果 where cmake 找不到任何结果回到 3.1 的脚本确认解压路径是不是真的存在。最常见的原因是解压时把外层目录又套了一层比如解压成 D:\tools\cmake-3.10.0-win64-x64\cmake-3.10.0-win64-x64\bin脚本里写的路径就对不上了。3.3 cmake-gui 在这版里够用什么时候别跟风命令行3.10.0 的 bin 目录里有 cmake-gui.exe它不是摆设。很多人一上来就追求全命令行操作其实在处理 Qt 的 CMAKE_PREFIX_PATH、OpenCV 的模块开关这类多路径、多开关场景时GUI 反而更直观。cmake-gui 打开后上面填源码目录下面填 build 目录点 Configure 第一次会弹生成器选择框选完再点 Generate。3.10 的 GUI 没有后来版本的自动搜索工具链提示但基本功能都在Add Entry 用来加 CMAKE_PREFIX_PATH 这种缓存变量Grouped 视图可以按 CMAKE、Qt、OpenCV 分类看变量比命令行敲 -D 一个个传肉眼核对舒服。我的习惯是第一次配置用 GUI因为要试探很多变量确认全部参数后把 GUI 里生成的 CMakeCache.txt 保留后面全部用命令行 cmake --build . 做增量构建。GUI 生成的缓存是纯文本你用编辑器打开也能看到每个 -D 参数的真实值排查问题比命令行回显更清楚。3.10 的 GUI 不会有新版本那种“首次配置自动探测 Ninja”的便利但别嫌它老它处理老工程的场景真够用。4. 用 CMake 3.10.0 构建一个最小 Windows C 工程可复制的四条命令4.1 先把 MSVC 环境拉起来vcvars64 比你想象的重要在 Windows 上用 CMake 配 Visual Studio 2017 的人最容易犯的错误是直接打开普通 cmd然后执行 cmake -G Visual Studio 15 2017 Win64。这个操作在多数机器上能通过配置阶段因为 VS 生成器是等编译时才调用 cl.exe 的而 cl 的环境变量没加载的话会在编译阶段报“找不到 cl.exe”或者直接编译失败。还有更进一步的情况是它能找到 cl但找不到 link.exe、rc.exe那些报错更隐蔽。正确做法是先加载 VS 开发环境。VS2017 里对应的是 vcvars64.bat通常藏在安装目录的 VC\Auxiliary\Build 下。Professional 版、Enterprise 版、Community 版路径前缀会不同BuildTools 单独安装又在另一个目录。典型调用是这样call C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\Build\vcvars64.bat注意是 call 不是直接执行因为 vcvars64.bat 里设置了大量临时环境变量直接执行是开个子进程设置完就没了不会影响当前命令行窗口。加载之后再执行 cl 或 where cl 就能看到 MSVC 编译器路径。CMake 在你用 VS 生成器时其实是靠自身寻找工具链不需要 vcvars但很多老项目会额外配置外部依赖和自定义命令这些命令里如果用了 cl、mt、rc 之类的工具没有 vcvars 就会失败。所以我建议养成习惯所有 CMake 命令都在 vcvars64 之后执行。如果你不想装完整 VS2017只想要编译器也可以考虑 mingw-w64 安装包加 MinGW Makefiles 生成器的组合。写法是 cmake -G MinGW Makefiles -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERg。但这套组合跟 Qt 5.9.4 的 msvc2017_64 预编译库不匹配链接 Qt 库时会因为符号约定不同翻车。选工具链之前先确认依赖库本身的编译约定这是我在老项目上最能省时间的经验。4.2 最小工程模板CMakeLists.txt 与四条构建命令先看一个我能直接抄的工程模板包含一个 main.cpp 和一个 CMakeLists.txt// main.cpp #include iostream int main() { std::cout legacy cmake ok std::endl; return 0; }cmake_minimum_required(VERSION 3.10) project(legacy_demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(legacy_demo main.cpp)这个 CMakeLists.txt 的写法体现了 3.10 时代的规范。cmake_minimum_required 放在第一行表示这个工程最低需要 3.10如果 CMake 版本低于它会直接报错project 指定工程名和语言LANGUAGES CXX 让 CMake 只探测 C 编译器不至于多花时间去探测 C 和 Fortran。CMAKE_CXX_STANDARD 设为 14 是因为 3.10 已经能很好处理 C14如果设 17老版本的某些 MSVC 版本会陷入部分标准支持不完整的尴尬。构建命令只有四条mkdir build cd build cmake -G Visual Studio 15 2017 Win64 .. cmake --build . --config Release第一行建 build 目录第二行切进去这两步的作用是把源码目录和构建目录分离。CMake 时代不应该在源码目录里直接产出临时文件否则哪天你想换生成器或者清理重编源码目录会被缓存文件污染得很难看。第三行是关键-G 指定生成器后面的 .. 是源码目录位置。因为我们在 build 子目录里.. 指回工程的根目录。第四行是老版本里最好用的命令之一cmake --build 会读取当前目录里已经生成的构建系统并驱动编译不需要再单独调 msbuild 或者 nmake。用 CMake 之后你可以完全不用手写 MakefileCMakeLists.txt 本身就是跨构建系统的描述文件。网上关于“makefile和cmake的区别”讨论很多落到这个版本上的直观区别就是你维护的是 CMakeLists.txt改一次语法就能同时生成 VS 工程、Ninja 脚本或 Makefile。这也是为何老项目宁可守着 3.10 也不转回 Makefile 的原因。4.3 必设参数CMAKE_PREFIX_PATH、CMAKE_BUILD_TYPE、CMAKE_INSTALL_PREFIX上面四条命令能跑通不带动两个参数的场景但真实老项目几乎没有不带依赖的。最常用的参数是 CMAKE_PREFIX_PATH它告诉 CMake 去哪找 SDK 的配置文件。拿 Qt 5.9.4 举例很多人把 Qt 装到 D:\Qt\Qt5.9.4然后在 CMake 里写 find_package(Qt5 COMPONENTS Core Widgets)结果配置时找不到原因就是 CMake 默认搜索路径里根本没有 D:\Qt 这一项。需要手动加cmake -G Visual Studio 15 2017 Win64 -DCMAKE_PREFIX_PATHD:/Qt/Qt5.9.4/5.9.4/msvc2017_64 ..这个参数的值不是 Qt 的安装根目录而是 Qt 库目录所在的那一层它下面需要能找到 lib\cmake\Qt5\Qt5Config.cmake。如果你传错了层级比如传成 D:/Qt/Qt5.9.4Qt 的配置文件找得到但版本探测多半会对不上。另一个常见参数是 CMAKE_BUILD_TYPE只对单配置生成器有效像 Ninja、MinGW Makefiles你需要写 -DCMAKE_BUILD_TYPERelease但对 Visual Studio 生成器构建类型是在构建时通过 --config Release 指定的写 CMAKE_BUILD_TYPE 不会报错但也没作用这就是参数在两种生成器下的行为差异。CMAKE_INSTALL_PREFIX 是另一个容易踩的参数。3.10 还没引入 cmake --install 命令那是 3.15 才有所以在 3.10 里安装是执行cmake --build . --config Release --target install默认的安装路径在 Windows 上是 C:\Program Files\legacy_demo如果你不想把文件装到系统盘就在配置阶段加 -DCMAKE_INSTALL_PREFIXD:/deploy/legacy_demo。注意 3.10 的这个参数必须在配置阶段传后期改 CMakeCache.txt 虽然也有用但很多子目录的 install 规则是配置时就展开的改晚了会导致一部分文件装错位置。这属于老版本特有的边界坑新版 CMake 也不会帮你兜着。5. 避坑记录cmake-3.10.0 在 Windows 上我踩过的 5 个坑5.1 现象CMD 提示“cmake 不是内部或外部命令”但明明解压好了原因rar 解压后bin 目录没进 PATH或者进了系统 PATH 但当前命令行窗口是在修改 PATH 之前打开的。Windows 的环境变量是在进程启动时读取的已经打开的 cmd 不会自动刷新。解决打开新 cmd或者执行 3.1 里的 cmake_env.bat。如果开新窗口还不行用 where cmake 查一下系统 PATH 里是否真的包含那个 bin 目录。另外一个高频原因解压时多套了一层目录你 PATH 里写的是 D:\tools\cmake-3.10.0-win64-x64\bin但实际解压路径是 D:\tools\cmake-3.10.0-win64-x64\cmake-3.10.0-win64-x64\bin这种路径嵌套在网盘压缩包里特别常见解压后务必先看一眼目录结构。5.2 现象cmake --version 显示的不是 3.10.0而是机器上的其他版本原因系统里之前装过 CMake 3.16、3.20 之类且它的路径排在当前 PATH 的前面。where cmake 会把所有候选路径列出来Nature 顺序决定优先使用谁。解决执行 where cmake 看清楚临时方案是直接用绝对路径调 D:\tools\cmake-3.10.0-win64-x64\bin\cmake.exe长期方案是把 3.10 的 bin 目录放到 PATH 最前面或者用 cmake_env.bat 在窗口内前置。我见过有人因此把新版 CMake 卸载了事后发现另一个项目必须用新版这就很麻烦。正确做法是让两个版本共存用脚本切换而不是粗暴卸载。5.3 现象配置时报错“could not find a package configuration file provided by Qt5”后面还跟着 qt5config.cmake 的路径原因CMake 在 CMAKE_PREFIX_PATH 指定的路径里没有找到 Qt5Config.cmake。常见的是 CMAKE_PREFIX_PATH 没有传或者传到了 Qt 安装根目录而正确指向应该是 msvc2017_64 那一层。也有更隐蔽的原因Qt 5.9.4 的 msvc2017_64 库要求使用 VS2017 工具链如果你用的是 MinGW 或 VS2015find_package 在解析 Qt5Config.cmake 内部依赖时会失败报错信息可能五花八门比如找不到 Qt5Core.dll 的导入库。解决先确认 CMakeCache.txt 里的 CMAKE_PREFIX_PATH 值再确认编译器生成器是 Visual Studio 15 2017 Win64最后确认你找的 Qt 目录名字是 msvc2017_64 而不是 msvc2015_64。对于多模块工程顶层 CMakeLists.txt 只放 add_subdirectory 和一个全局 find_package 就够Qt 组件拆到各自模块里找不然每个子目录都 find 一遍 Qt5配置阶段会慢得让人怀疑人生。5.4 现象配置时报编译器识别失败CMakeError.log 里写“The CXX compiler identification is unknown”原因这在 Windows 上八成是你没加载 vcvars64CMake 去探测 cl.exe 时找不到编译器在 Linux 上也有变体网上常见那个“cmake error at /usr/share/cmake-4.2/modules/cmakedeterminecompilerid.cmake:9”其实就是编译器探测失败的一种表现指向的是新版 CMake 在探测 C 编译器时连测试程序都编译不过。解决Windows 上先执行 4.1 的 vcvars64 调用再重新配置Linux 上检查 g 是否安装完整、gcc 和 g 版本是否一致。还有一个 Windows 特有的解决关键CMake 在探测失败后会把详细错误写进 build 目录下的 CMakeFiles\CMakeError.log这个文件里真的能看到 cl.exe 被调用时的完整命令行和输出。我建议每次碰到“unknown”第一反应不是重装 CMake而是打开这个日志找原因它往往比你在网上搜报错更快。5.5 现象装了 VS2019 或 VS2022用 3.10 配置时报“Could not create generator‘Visual Studio 16 2019’”原因CMake 3.10 本身不认识 2019 生成器。VS2019 用的是 Visual Studio 16 2019CMake 3.14 才开始正式支持3.10 不在支持范围。这不是安装包问题是版本代际不匹配。解决如果项目依赖必须锁 CMake 3.10解决方案是安装 VS2017 BuildTools配置时继续用 Visual Studio 15 2017 生成器如果项目可以接受新 CMake就换装 3.14 以上版本。还有一条中间路线用 VS2019 安装包的 MSVC 工具链配合 Ninja 生成器手动指定 CMAKE_C_COMPILER 为 VS2019 的 cl.exe 路径但这么做等于绕开了 CMake 的生成器保护逻辑部分 CMake 自定义命令仍可能因为找不到 VS 环境而失败。我一般不推荐这种玩法除非你对工具链加载原理已经很清楚。6. 让旧版 CMake 在机器上和新版共存工具链切换与升级界限6.1 快速切换脚本一个 cmake_env.bat 解决版本打架在同一台机器上同时保留 CMake 3.10.0 和 CMake 3.20 是完全可行的重点在于不要让它们同时出现在同一个命令行窗口的 PATH 的前缀部分。我把 3.1 的脚本扩展成双版本切换版echo off set CMAKE310_HOMED:\tools\cmake-3.10.0-win64-x64 set CMAKE_NEW_HOMED:\tools\cmake-3.20.0-win64-x64 :select echo 1 - CMake 3.10.0 echo 2 - CMake 3.20.0 set /p verchoose: if %ver%1 set CMAKE_HOME%CMAKE310_HOME% if %ver%2 set CMAKE_HOME%CMAKE_NEW_HOME% set PATH%CMAKE_HOME%\bin;%PATH% cmake --version这个脚本在你需要切版本时直接选择数字即可省去反复修改系统环境变量的操作。逻辑上它只把指定版本的 bin 目录临时插到 PATH 前缀不影响全局设置也不会把系统 PATH 写坏。配合 VSCode 的 CMake Tools 时如果你的工作区需要指定老版本可以在 .vscode/settings.json 里写{ cmake.cmakePath: D:\\tools\\cmake-3.10.0-win64-x64\\bin\\cmake.exe }这样 VSCode 里调用的 CMake 就是 3.10.0调试源代码时底层走的还是你指定的编译器。新版 CMake Tools 的很多功能依赖新 CMake 的文件 API3.10 支持的文件 API 版本比较早预设CMakePresets.json功能不可用但基本的 configure、build、debug 流程没有影响还算顺手。6.2 升级界限表什么情况必须告别 3.10.0给你一张我常用的判断表照着对照项目情况即可继续留在 3.10.0必须升级 CMakeQt 5.9.x / Qt 5.10.x 项目Qt6 或新版本 Qt 的跨平台工程VS2017 / VS2015VS2019 / VS2022 生成器需求C14 及以下标准需要 C20/23 的编译特性支持OpenCV 3.4.x 源码构建CUDA 新版本、新版 OpenCV现有 CMakeLists.txt 最低版本 3.10想用 cmake --install、CMakePresets这里最容易被忽视的是CMake 3.10 本身也能构建 C17 项目但它不会帮你做太严格的标准检查老版本在生成 VS 工程时的“/std:clatest”标志处理方式和新版不同如果工程里用了较新的标准库头文件可能在新版上能编过、在 3.10 上报一堆语法错误。这时候要分清是项目问题还是 CMake 版本问题我的判断标准是先看编译日志里是不是全部报 STL 头文件内部的错误如果是基本可以断定是工具链代际太老别死守老版本。最后说一句我自己的教训那一次我把一个 Qt 5.9 的老项目从 CMake 3.10 升到了 3.20configure 一次通过心里还挺高兴结果链接时出现十几个 LNK2019查了整整一个下午最后发现是 CMake 新策略默认改变了隐式链接 Qt 插件的方式。从那以后老项目换 CMake 大版本我必做的一步是先读一遍 release notes 里带 CMP 标记的变更再决定要不要升。这个习惯帮我躲过了后面好几次同类翻车。这个 cmake-3.10.0-win64-x64.rar 不是性能最优、不是功能最全但对特定一代工程就是合适的工具。按你自己项目的依赖代际做选择别被“越新越好”带跑偏。希望帮到你。本文还有配套的精品资源点击获取