简介：这是一份CMake 3.14.2 Windows 64位版本的安装资源包，面向需要在64位Windows环境下管理C/C++项目构建的开发者，解决跨平台编译配置繁琐、依赖关系复杂的问题。CMake以平台无关的CMakeLists.txt描述构建规则，可自动生成Visual Studio解决方案、Makefile等文件，尤其适合与OpenCV、VTK等大型库配合使用，在计算机视觉与机器学习项目中完成编译配置与调试环境搭建。压缩包共包含5681个文件，整体大小约29.58MB，主要内容包括可执行的安装程序、cmake-gui与ccmake图形/命令行工具，以及txt、html、rst格式的用户手册与开发者文档；大量.cmake模块文件用于查找依赖库和配置编译选项，另有in、json、c/cpp等源码或配置示例，方便参考和二次开发。目前已有168人学习下载。资源内集成了完整的CMake命令参考、模块清单、属性和策略说明，还有ctest、cpack等辅助工具的使用说明，能够帮助用户系统掌握从编写CMakeLists.txt到生成构建文件、执行测试、打包发布的全流程。安装包内文件按功能分类存放，目录结构清晰，便于按需查找；OpenCV视觉开发者使用这套工具链能显著降低配置成本，提升构建效率与可控性。

1. cmake-3.14.2-win64-x64 是什么：Windows 下 C++ 构建链的第一块拼图

搜索这个文件名的人，多半刚从镜像站或软件库保存了一个安装包，正犹豫要不要解压、怎么配环境变量。cmake-3.14.2-win64-x64 这个文件名已经把关键信息标完了：3.14.2 是版本号，win64 表示 64 位 Windows 系统，x64 是目标 CPU 架构。它是 CMake 的绿色压缩包，解开就能用，不用跑安装向导。CMake 本身不编译代码，它读取你项目里的 CMakeLists.txt，生成一套你本机编译器真正认的工程文件——Visual Studio 工程、MinGW 的 Makefile 或 Ninja 构建文件，再由编译器完成编译。适合刚把项目从 Linux 迁到 Windows、在 VSCode 里装好 CMake Tools 却找不到 Configure 按钮、或者被 Qt5Config.cmake 报错卡住的人。下面按我实际做过的流程，讲清安装、配对、命令和最容易翻车的地方。

2. 安装这个包的完整流程：解压、PATH 写入与三分钟验证

2.1 先分清 zip 和 installer：这个文件名对应的是绿色版安装包

CMake 官方在 Windows 上给两种分发形式：zip 压缩包和 msi 安装程序。文件名 cmake-3.14.2-win64-x64 对应的是 zip 那一类，解压即用，不写注册表，卸载就是删文件夹。msi 版则有安装向导，会在开始菜单建快捷方式，安装时还能勾选“Add CMake to the system PATH for all users”，省去手动配环境变量的步骤。

两种形式里的二进制内容完全一样，bin 目录下的 cmake.exe、cmake-gui.exe、ctest.exe、cpack.exe 都是同一套，差别只在于安装登记方式和卸载方式。如果你是在公司内网、没有管理员权限，或者机器上想同时留一个 3.14.2 和更新的 CMake 版本，zip 版明显更合适；个人电脑图省事，msi 版也不差。我自己通常选 zip，因为不用被安装向导里那些勾选框牵着走，目录往哪放完全自己说了算。下表可以直接对着选：

2.2 解压路径怎么选，以及把 bin 写进 PATH 的最稳写法

解压目标建议选一个纯英文、没有空格的路径，例如 C:\tools\cmake-3.14.2-win64-x64。原因后面避坑章节会展开：非英文路径在 CMake 3.14.2 和部分编译器前端之间容易出编码问题，空格则容易让 Makefile 脚本在传递路径时断掉。解压后目录里有几个关键部分：bin 下是 cmake.exe、cmake-gui.exe、ctest.exe、cpack.exe，share/cmake-3.14/Modules 里是一大堆 .cmake 模块文件，find_package 查找库的全套逻辑都靠它们，不能随手删掉。

Path 建议写到用户级环境变量，而不是系统级。用户级不需要管理员权限，也不会污染其他账号。打开 PowerShell，把下面这段粘进去，它会去读当前用户的 Path，把 CMake 的 bin 目录拼到最前面：

$cmakeRoot = 'C:\tools\cmake-3.14.2-win64-x64' $userPath = [Environment]::GetEnvironmentVariable('Path', 'User') [Environment]::SetEnvironmentVariable('Path', $cmakeRoot + '\bin;' + $userPath, 'User')

这段的逻辑是：先用 GetEnvironmentVariable 拿到用户 Path 的原始值，再在头部拼接 cmake 的 bin 路径，最后写回用户级环境变量。把新路径放在最前面，是为了避免机器上已有的旧版 CMake 抢先被命中。

提示：不要用 setx 命令去改 Path。setx 对命令行长度有限制，超过一定字符会把整个 Path 截断，很多人在这上面吃过亏。

如果你更想用图形界面配，也可以按 Win 键搜索“编辑账户的环境变量”，在用户变量里找到 Path，新建一行填 C:\tools\cmake-3.14.2-win64-x64\bin。需要注意，已经打开的 cmd 或 PowerShell 不会自动刷新环境变量，改完务必新开一个窗口再验证。

2.3 验证 cmake 可用：版本、位置、生成器列表三条命令

配置完成后，新开一个 cmd 或 PowerShell，依次执行这三条：

where cmake cmake --version cmake --help

where cmake 会列出当前 PATH 里所有 cmake.exe 的位置，第一个就是实际命中的那个。如果第一个位置不是你刚解压的路径，说明有旧版本占了坑，需要回到环境变量调整顺序。cmake --version 的输出第一行应该是 cmake version 3.14.2。cmake --help 用来确认生成器列表，往下翻能看到 Visual Studio 15 2017、Visual Studio 16 2019、MinGW Makefiles、Ninja 等条目，这些是 CMake 能在 Windows 上生成的构建工程格式。

顺手再把图形界面也验证一下：

Start-Process 'C:\tools\cmake-3.14.2-win64-x64\bin\cmake-gui.exe'

cmake-gui 正常弹出后，界面顶部有两个输入框：源码目录和构建目录，中间是 Configure 和 Generate 两个大按钮。第一次点 Configure 会弹出生成器选择框，选完以后那句“Configuring done”就是配置成功的信号。图形界面适合不熟悉命令行参数的人，也适合排查路径问题时快速观察缓存的生成器和编译器信息，但日常重复构建我建议还是回到命令行。

3. 跑通第一个 CMake 工程：最小 CMakeLists.txt 与两条构建命令

3.1 从 Makefile 到 CMake：它生成什么，不编译什么

很多人在 Windows 上第一次接触 CMake 是因为看开源项目时遇到了 Makefile 和 CMake 的取舍问题。两者不是替代关系：Makefile 是给 make 用的规则文件，里面写死了怎么编译、怎么链接；CMake 则是一个跨平台的构建系统生成器，读 CMakeLists.txt，生成 Makefile、Ninja 文件或 Visual Studio 工程。换句话说，CMake 管的是“用哪种编译方式、编译哪些文件、链接哪些库”，真正做编译的还是你的编译器。

它会直接调用本机工具链里的 cl.exe、g++ 或 clang，这一点在 Windows 上尤其要紧：CMake 默认选择的生成器取决于你机器上装了哪些编译环境。如果装了 Visual Studio 2019，默认通常是 Visual Studio 16 2019；如果只装了 MinGW-w64，默认可能会失败，需要你显式指定生成器。弄清楚 CMake 只是“生成构建工程、调度构建工具”这一层，后面很多莫名其妙的现象就能解释通了。

3.2 最小工程文件：main.cpp 配一个 5 行的 CMakeLists.txt

在 C:\code\hello 下建一个最小工程，两个文件就够了：

#include <iostream> int main() { std::cout << "hello cmake" << std::endl; return 0; }

对应 CMakeLists.txt 写 5 行：

cmake_minimum_required(VERSION 3.14) project(hello LANGUAGES CXX) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(hello main.cpp)

第一行声明这个工程最少需要 CMake 3.14，低了直接拒绝配置；第二行声明工程名 hello，只用 C++ 语言；中间两行把 C++ 标准固化为 C++11，防止编译器默认标准不一致导致行为差异；最后一行把 main.cpp 编译成名为 hello 的可执行文件。这样一个最小工程，足够验证 CMake 3.14.2 在这台 Windows 机器上的整套链路是否通畅。

3.3 cmake -S . -B build 与 cmake --build build 的参数说明

在 C:\code\hello 目录下执行两条命令：

cmake -S . -B build cmake --build build

-S . 指源码目录是当前目录，-B build 指构建目录叫 build，这个目录不需要你手动创建，CMake 会自己建。-S 和 -B 是 CMake 3.13 开始支持的参数，到了 3.14.2 已经很顺手，不用再写老教程里那套 cd build && cmake .. 的绕路流程。

第一条命令做配置和生成：它读 CMakeLists.txt，把检测到的编译器、路径、生成器类型写进 build 目录下的 CMakeCache.txt，然后生成对应的工程文件。第二条命令才是真正调用编译器完成构建。如果本机装的是 Visual Studio，生成的是一套 .sln 加 .vcxproj；如果指定了 MinGW，生成的是 Makefile，cmake --build 会自动调用 mingw32-make 去执行。输出里看到 Configuring done 和 Build files have been written to，说明配置那一步已经过去；随后能看到 cl.exe 或 g++ 的编译输出，构建就算真正跑起来了。

需要调整参数时，常见做法是首次配置就给足信息：

cmake -S . -B build -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release cmake --build build

-G 指定生成器，第一次配置时必须给，之后改生成器会很麻烦；-D 用来设置缓存变量，这里把构建类型设为 Release。-DCMAKE_BUILD_TYPE 只在 MinGW Makefiles、Ninja 这类单配置生成器里生效。如果用的是 Visual Studio 生成器，构建类型不是配置时定的，而是构建时用 --config 指定：

cmake --build build --config Release

3.14.2 还支持 --parallel 给构建进程加并行度，比如 cmake --build build --parallel 4，效果相当于同时用 4 个编译任务。

4. 与编译器配对：MSVC、MinGW、Qt5 三个高频场景

4.1 MSVC：从 x64 Native Tools 命令行启动，生成 VS 工程

Windows 上最省事的 CMake 配对方式是 Visual Studio。不是因为 CMake 偏爱它，而是因为 VS 自带的 MSVC 工具链完整，环境变量齐全，CMake 检测时几乎不会出意外。但有个操作容易被忽略：不要在普通 cmd 或 PowerShell 里直接敲 cmake，而是从开始菜单里启动“x64 Native Tools Command Prompt for VS 2019”。这个入口会把 cl.exe、link.exe 和一堆 INCLUDE、LIB 环境变量一次性配好，CMake 配置阶段才能找到编译器。

进了这个命令行，验证 cl 能用后，配置命令如下：

cl cmake -S . -B build -G "Visual Studio 16 2019" -A x64 cmake --build build --config Release

-G "Visual Studio 16 2019" 指定生成器，-A x64 指定目标架构。Visual Studio 生成器属于多配置生成器，一份工程文件里同时包含 Debug、Release、RelWithDebInfo 等配置，所以配置阶段不需要也不接受 -DCMAKE_BUILD_TYPE，构建时用 --config Release 选其中一套。

有一点要注意：CMake 3.14.2 生成器列表里最高是 Visual Studio 16 2019，它不认识 Visual Studio 17 2022。如果机器上只装了 VS 2022，这个版本的 CMake 在配置时会直接报无法识别生成器。遇到这种情况要么本机升级 CMake，要么另想办法，别在 3.14.2 上硬等。

4.2 MinGW：-G "MinGW Makefiles" 与编译器环境变量

不想装 VS 的人，最常用的是 MinGW-w64。这个组合的关键在于让 CMake 找到 g++、gcc 和 mingw32-make。MinGW 的安装目录里同时包含编译器与 make 工具，安装后确认 bin 目录已加入 PATH。

配置命令：

cmake -S . -B build -G "MinGW Makefiles" -DCMAKE_CXX_COMPILER=g++ -DCMAKE_BUILD_TYPE=Release cmake --build build

-G "MinGW Makefiles" 告诉 CMake 生成 Makefile 而不是 Visual Studio 工程；-DCMAKE_CXX_COMPILER=g++ 是显式指定 C++ 编译器，防止 CMake 检测时去 PATH 里找一堆名字相近的工具链；-DCMAKE_BUILD_TYPE=Release 在单配置生成器里生效，相当于在生成的 Makefile 里注入 -O2 一类的优化参数。

这里有个高频坑：如果 PATH 里同时存在 MSYS2 或 Git Bash 的目录，CMake 可能在配置阶段报 sh.exe was found in your PATH，然后拒绝继续。原因是 MinGW Makefiles 生成器在检测到 sh.exe 时，担心 make 会被 bash 脚本干扰，宁可中止配置。解决方法是把 MinGW 的 bin 目录放在 PATH 最前面，并尽量在干净的 cmd 里执行配置。

4.3 Qt5：CMake Error at .../qt5config.cmake 的定位思路

搜索热词里有一串很具体的报错：CMake Error at c:/qt/qt5.9.4/5.9.4/msvc2017_64/lib/cmake/qt5/qt5config.cmake。这个错误我在配合 Qt 的老项目时见过太多次。工程里写了 find_package(Qt5 COMPONENTS Widgets)，CMake 在默认路径里找不到 Qt5Config.cmake，于是要么把整个查找过程的中断信息抛出来，要么给出一个含义模糊的 Not found。

问题的根源不是 Qt 坏了，而是 CMake 不知道 Qt 装在哪里。Qt5Config.cmake 在 Qt 安装目录的 lib/cmake/Qt5 下面，要让 find_package 找到它，得把 Qt 的根目录告诉 CMake：

cmake -S . -B build -DCMAKE_PREFIX_PATH=C:/Qt/qt5.9.4/5.9.4/msvc2017_64

CMAKE_PREFIX_PATH 是 find_package 搜索前缀，CMake 会在 <前缀>/lib/cmake/<名字> 这样的结构里自动寻找 *Config.cmake。把 prefix 指到 Qt 的那一层，qt5config.cmake 就会被命中。同样的思路也适用于找不到 Eigen3、OpenCV、Boost 的场景：先找到对应库的 *Config.cmake 或 *-config.cmake 在哪里，再把它的父目录路径填进 CMAKE_PREFIX_PATH，或者直接设置 XXX_DIR 指到那个目录。

还有一层容易忽略：Qt 5.9.4 的 msvc2017_64 包是用 VS2017 工具链预编译的。CMake 3.14.2 配 VS2019 时，如果编译器与 Qt 二进制并不完全兼容，link 阶段会冒出一堆未定义符号，这类问题配置阶段看不出来，要把注意力放到链接错误文本里是不是混着 Qt 的库名。

4.4 嵌入式交叉编译：用 toolchain.cmake 给 STM32 指定编译器

在 VSCode 里用 CMake 开发 STM32，和本机构建完全是两码事：本机 Windows 和板卡 ARM 架构不同，编译器也得换成 arm-none-eabi-gcc。CMake 默认会探测本机编译器，交叉编译时必须用一个工具链文件把目标系统和编译器写死。常见做法是新建 toolchain-stm32.cmake：

set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-none-eabi-gcc) set(CMAKE_CXX_COMPILER arm-none-eabi-g++) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)

配置时用 CMAKE_TOOLCHAIN_FILE 把这个文件传进去：

cmake -S . -B build -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain-stm32.cmake -DCMAKE_BUILD_TYPE=Release

前三行在告诉 CMake 这不是在 Windows 上做本机构建，目标系统叫 Generic、处理器是 ARM；中间两行指定交叉编译器；最后一行很关键——交叉编译时 CMake 会在配置阶段尝试编译一个小程序来验证编译器，没有链接器支持或库不完整时这一步容易失败，改成 STATIC_LIBRARY 可以跳过链接检测。STM32 的启动文件、链接脚本由芯片厂商或 HAL 库提供，CMake 的角色是把它们和你的源码一起编进可执行文件。

5. 避坑：Windows 上 CMake 3.14 最常见的 5 个翻车现场

5.1 刚装完，cmake --version 显示的还是旧版本

现象：下载并配置了 3.14.2，新开一个 cmd 执行 cmake --version，输出的却是 3.5.1 或某个更早的版本，甚至提示“不是内部或外部命令”。

原因：机器上原本就装过 CMake，旧路径排在 PATH 前面；或者新路径写入的是用户级环境变量，但当前终端会话没有刷新。也有可能改完环境变量后没有新开窗口，直接在旧窗口里验证。

解决：先执行 where cmake，看命中的是不是刚解压的路径。如果不是，把新路径调到 PATH 最前面，然后新开终端。临时验证不想改 PATH，可以用完整路径 C:\tools\cmake-3.14.2-win64-x64\bin\cmake.exe --version 先确认文件本身可用，再回头处理环境变量。

5.2 VSCode 状态栏一直不出现 Configure 按钮

现象：VSCode 里装了 CMake Tools 扩展，打开了工程目录，但底部状态栏没有 Configure 按钮，也没有预设的构建类型列表。

原因：十有八九不是插件问题。CMake Tools 插件本身不附带 cmake，它只是去 PATH 或配置项里找 cmake.exe。文件包里只有源码目录没有 CMakeLists.txt 时，插件会认为这不是一个待配置工程；另一种情况是 VSCode 启动时没有读到新设置的环境变量，或者 cmake.cmakePath 仍指向旧版本。

解决：先在 VSCode 的设置里搜 cmake.cmakePath，把它显式覆盖为 C:\tools\cmake-3.14.2-win64-x64\bin\cmake.exe；确认打开的是包含 CMakeLists.txt 的项目根目录，不是某个深层子目录；然后重启 VSCode。这些做齐后底部状态栏会出现 Configure 按钮，之后再选构建类型、按 F5 就能调试源代码。VSCode 从图标启动时，环境变量读取时机确实容易让人困惑，这属于配置生效时序问题，不是 CMake 本身的问题。

5.3 照抄新教程，用了 CMakePresets.json 或 cmake --install

现象：按网上较新的教程写了 CMakePresets.json，执行 cmake --preset configure 直接报 unrecognized option；或者执行 cmake --install build 也报参数不认识。

原因：这两样都是后面几个版本才加入的能力。cmake --install 是 CMake 3.15 才有的命令，CMakePresets.json 的支持出现得更晚。3.14.2 发布时这两条路都还不存在，新教程通常不会专门标注最低版本要求，跟着做自然翻车。

解决：把命令换成 3.14.2 支持的老组合。安装目标这一步，3.14 时代一般是用 cmake --build build --target install，或者配置时把 CMAKE_INSTALL_PREFIX 设好，构建后手工复制产物。如果项目必须锁在 3.14.2，资料要么看 CMake 3.14 的官方文档，要么把新教程里的 preset 参数翻译成 -D 缓存变量。

5.4 源码或安装路径带中文，cmake-gui 和编译器一起翻车

现象：源码目录是 C:\Users\张三\project，cmake-gui 配置时生成器报错，或者 cl.exe / g++ 提示打不开源文件，MinGW 环境下尤其明显。

原因：CMake 3.14.2 对中文等非 ASCII 路径的处理不像新版本那么完善，加上 Windows 控制台的代码页和编译器前端对路径编码的理解不一致，路径里的中文在传递过程中会变成乱码。空格路径的问题则是 Makefile 在展开时会把路径切碎。

解决：源码目录、构建目录、CMake 安装目录全部放到纯英文路径下，例如 C:\code\project、C:\tools\cmake-3.14.2-win64-x64。路径中间也不要留空格，Visual Studio 生成器能容忍空格，但 MinGW Makefiles 对空格极不友好。这属于最不值得浪费时间的坑，挪完目录立刻就好。

5.5 -DCMAKE_BUILD_TYPE=Release 对 VS 生成器无效

现象：配置时明明加了 -DCMAKE_BUILD_TYPE=Release，生成的 Visual Studio 工程里 Release 配置却看不到预期的优化参数，构建结果体积也明显偏大。

原因：Visual Studio 生成器是多配置生成器，工程文件里同时存在 Debug、Release、RelWithDebInfo 多种配置，CMAKE_BUILD_TYPE 这类配置时才确定的变量只在单配置生成器里起作用。3.14.2 不会因为你写了 Release 就把其他配置删掉。

解决：用 Visual Studio 生成器时，构建阶段通过 --config 指定：

cmake --build build --config Release

如果是 VSCode 的 CMake Tools，用底部状态栏或命令面板里的构建类型切换，它内部最终也是执行 --config Release。区分清楚哪一步定生成器类型、哪一步定构建类型，这个坑以后再也不会遇到。

6. 让 3.14.2 在 Windows 上用顺手的三个习惯

6.1 一切诡异行为先怀疑缓存

CMake 把配置结果写在 build 目录里的 CMakeCache.txt 中。改了 CMakeLists.txt 却发现行为没变，或者 -D 参数改了像没改，通常不是 CMake 没读到文件，而是缓存还在按旧配置执行。遇到这种情况，别一层层找原因，直接删掉 build 重建更省事：

cmake -E remove_directory build cmake -S . -B build

cmake -E 是 CMake 自带的跨平台文件操作入口，remove_directory 相当于 rm -rf。这套操作在 Windows 上的效果比手动去资源管理器删目录更可控，也是老项目换编译器、换生成器之后最稳妥的后悔药。

6.2 构建失败先翻两个日志，而不是重敲命令

CMake 配置失败时，会在 build 目录的 CMakeFiles 下留下 CMakeError.log 和 CMakeOutput.log。前者记录编译器探测失败的详细输出，后者记录探测步骤成功时的输出。交叉编译 STM32 或 Qt 报错时，与其反复猜测，不如先打开这两个文件，搜索 error、not found、cannot 这些关键字。很多“疑难杂症”的答案就藏在日志里：链接器路径不对、编译器缺少某个头文件、库的架构不匹配，都能在日志里看到原始信息。构建阶段如果也想看完整命令，给 cmake --build 加 --verbose 即可。

6.3 在项目里钉死最低版本和实际版本

CMakeLists.txt 里的 cmake_minimum_required(VERSION 3.14) 不只是写个声明，它决定了解析这份工程的 CMake 必须大于等于哪个版本。团队协作时，如果有人在 3.20 的机器上写了新语法，而另一台机器还是 3.14.2，配置阶段就会断在语法解析上。我养成的习惯是：工程里把最低版本写成团队中最低的那台机器能跑的版本，避免新语法被意外混入；本机也尽量与 CI 用的 CMake 版本保持一致。

自己的一个教训是从前在一台旧机器上用 3.14.2 去构建一份已经用了新版语法的高版本工程，反复报错后才意识到是版本差异，白白耗了一个下午。之后每接手一个老项目，第一件事就是先确认它声明的 CMake 最低版本与本机实际版本是否匹配。CMake 3.14.2 虽然是 2019 年的版本，但至今仍有不少老项目钉着它，只要记住缓存、日志、版本这三个抓手，Windows 上这套构建流程就能一直跑得安稳。希望帮到你。

本文还有配套的精品资源，点击获取