简介这是一份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因为不用被安装向导里那些勾选框牵着走目录往哪放完全自己说了算。下表可以直接对着选对比项zip 绿色版msi 安装版安装动作解压到目标目录运行安装向导写入注册表否是开始菜单快捷方式无有PATH 配置手动设置安装时可勾选卸载方式删除目录控制面板卸载适合场景无管理员权限、想多版本共存个人机器、不想手动配环境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.exeshare/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 --helpwhere 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.execmake-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 标准固化为 C11防止编译器默认标准不一致导致行为差异最后一行把 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生成的是 Makefilecmake --build 会自动调用 mingw32-make 去执行。输出里看到 Configuring done 和 Build files have been written to说明配置那一步已经过去随后能看到 cl.exe 或 g 的编译输出构建就算真正跑起来了。需要调整参数时常见做法是首次配置就给足信息cmake -S . -B build -G MinGW Makefiles -DCMAKE_BUILD_TYPERelease cmake --build build-G 指定生成器第一次配置时必须给之后改生成器会很麻烦-D 用来设置缓存变量这里把构建类型设为 Release。-DCMAKE_BUILD_TYPE 只在 MinGW Makefiles、Ninja 这类单配置生成器里生效。如果用的是 Visual Studio 生成器构建类型不是配置时定的而是构建时用 --config 指定cmake --build build --config Release3.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_COMPILERg -DCMAKE_BUILD_TYPERelease cmake --build build-G MinGW Makefiles 告诉 CMake 生成 Makefile 而不是 Visual Studio 工程-DCMAKE_CXX_COMPILERg 是显式指定 C 编译器防止 CMake 检测时去 PATH 里找一堆名字相近的工具链-DCMAKE_BUILD_TYPERelease 在单配置生成器里生效相当于在生成的 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 Qt5CMake 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 的根目录告诉 CMakecmake -S . -B build -DCMAKE_PREFIX_PATHC:/Qt/qt5.9.4/5.9.4/msvc2017_64CMAKE_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.cmakeset(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_FILEtoolchain-stm32.cmake -DCMAKE_BUILD_TYPERelease前三行在告诉 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\张三\projectcmake-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_TYPERelease 对 VS 生成器无效现象配置时明明加了 -DCMAKE_BUILD_TYPERelease生成的 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 buildcmake -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 上这套构建流程就能一直跑得安稳。希望帮到你。本文还有配套的精品资源点击获取
