简介本资源为 CMake 3.24.4 官方 Windows 64 位二进制发行版安装包面向 C/C 开发者、跨平台项目构建工程师及初学者用于替代 Visual Studio 内置构建系统或集成到 CI/CD 流程中解决多平台项目配置、依赖管理与自动化编译难题。压缩包共含 2000 个文件主体为 1209 个文本格式的官方文档含变量说明、命令参考、策略定义等辅以 791 个 HTML 格式的交互式帮助页面如 cmake.1、ctest.1、cmake-file-api.7 等全面覆盖构建脚本编写、测试驱动开发、预设配置presets、生成器表达式等核心功能总大小 38.24MB开箱即用无需编译。目前已有 482 人学习下载资源结构严格遵循 CMake 官方文档组织逻辑HTML 文件支持本地离线浏览txt 文件便于快速检索关键语法与参数是构建知识体系与日常开发查证的可靠本地化文档集。1. CMake 3.24.4 Windows x86_64 安装包不是“点下一步就完事”的黑匣子而是你 VS Code / Qt / MinGW 项目真正能跑起来的底层齿轮你是不是也遇到过这些场景在 VS Code 里配好 CMake Tools 插件底部状态栏死活不显示 Configure 按钮Qt Creator 报错CMake Error at C:/Qt/Qt5.9.4/5.9.4/msvc2017_64/lib/cmake/Qt5/Qt5Config.cmake但翻遍 CMakeLists.txt 却找不到问题在哪用 MinGW 编译一个简单 hello world 都卡在Could NOT find Threads (missing: Threads_FOUND)甚至刚解压完 cmake-3.24.4-windows-x86_64.zip双击 cmake-gui.exe 就弹窗说“无法启动此程序因为计算机中丢失 MSVCP140.dll”——别急这不是你代码写错了也不是环境变量没加对而是你手里的这个 zip 包根本没被当成“可执行的构建系统”而只被当成了一个“带 GUI 的绿色软件”。CMake 3.24.4 for Windows x86_64 不是安装器它是一套完整、自包含、无需注册表写入的构建工具链运行时。它不依赖 Visual Studio 安装目录但能无缝对接 MSVC、MinGW-w64、Clang-CL它自带 Ninja 构建后端却默认不启用它的cmake.exe是命令行核心cmake-gui.exe是可视化外壳ctest.exe和cpack.exe是验证与打包孪生兄弟——四者缺一不可。这份资源适合所有正在用 Windows 做 C/C 工程开发的从业者从刚学 CMake 教程、卡在add_executable报错的新手到维护跨平台 Qt 项目的中级工程师再到需要在 CI 流水线中稳定调用 CMake 的 DevOps 同学。它解决的不是“怎么装”而是“装完之后为什么 configure 总失败、generate 总报错、build 总找不到编译器”这一整条链路的可信起点。2. 解压即用的本质理解 cmake-3.24.4-windows-x86_64.zip 的文件结构与运行时契约CMake 官方发布的 Windows 二进制包.zip格式与传统.msi安装包有本质区别它不写注册表、不改系统 PATH、不创建开始菜单快捷方式也不校验 VC 运行库是否预装。它是一个“自洽型工具包”其全部功能都封装在解压后的目录树中。理解这个结构是你避免后续所有玄学报错的第一步。2.1 文件布局四个核心可执行体 两套数据资产解压cmake-3.24.4-windows-x86_64.zip后你会看到一个顶层目录如cmake-3.24.4-win64-x64其内部结构高度标准化cmake-3.24.4-win64-x64/ ├── bin/ # 所有可执行文件所在 │ ├── cmake.exe # 主命令行入口支持 -G, -S, -B, --preset 等全部现代参数 │ ├── cmake-gui.exe # 图形界面本质是 cmake.exe 的 Qt 封装依赖同目录下 Qt DLL │ ├── ctest.exe # 单元测试驱动器用于执行 add_test() 定义的测试用例 │ └── cpack.exe # 打包生成器配合 CPACK_* 变量生成 NSIS/ZIP/TAR.GZ 安装包 ├── doc/ # HTML 格式官方文档离线可用含完整命令参考与变量手册 ├── share/ # CMake 运行时核心资产 │ ├── cmake-3.24/ # 版本号子目录存放所有模块、宏、脚本 │ │ ├── Modules/ # 超过 200 个 .cmake 文件FindXXX.cmake如 FindOpenSSL.cmake、CheckXXX.cmake、GNUInstallDirs.cmake 等 │ │ ├── Templates/ # 项目模板如 VS Project、Xcode供 cmake -G 生成器调用 │ │ └── EditorSupport/ # 语法高亮配置VS Code、Sublime Text、Notepad │ └── licenses/ # MIT 许可证文本确认商业项目合规性 └── license.txt # 主许可证文件提示share/cmake-3.24/Modules/是 CMake 的“大脑”。当你写find_package(Threads REQUIRED)却报错Could NOT find Threads问题几乎一定出在这里——要么你用的是旧版 CMake3.1.0要么你误删了share/cmake-3.24/Modules/FindThreads.cmake或者你的CMAKE_MODULE_PATH被错误覆盖。这个目录不能动也不能替换为其他版本的 Modules。2.2 运行时依赖Windows 上唯一必须的“外部条件”CMake 3.24.4 for Windows x86_64 是静态链接大部分依赖的但它必须依赖微软的 Visual C 2015–2022 运行库vcruntime140.dll,msvcp140.dll,concrt140.dll。这不是 CMake 自己的问题而是 Qt GUI 组件和部分 Windows API 调用所必需。验证方法PowerShell# 进入解压目录的 bin/ 子目录 cd .\cmake-3.24.4-win64-x64\bin\ # 检查 cmake-gui.exe 依赖的 DLL Get-ChildItem cmake-gui.exe | ForEach-Object { $deps Get-Command $_.FullName -ErrorAction SilentlyContinue | Select-Object -ExpandProperty DLLDependencies -ErrorAction SilentlyContinue if ($deps) { $deps } else { No explicit DLL deps found (likely statically linked) } } # 更直接尝试运行并捕获缺失 DLL .\cmake-gui.exe 21 | Out-String如果报错MSVCP140.dll 丢失说明你的系统缺少 VC 2015–2022 运行库。不要下载网上来路不明的 DLL 补丁包——这是最典型的“翻车”源头。正确做法是下载微软官方离线安装包vc_redist.x64.exe对应 x86_64 系统从 Microsoft C Redistributable for Visual Studio 2015–2022 页面获取最新版以管理员权限运行安装即使提示“已安装”也强制修复注意cmake.exe命令行版对运行库依赖更轻多数情况下仅需vcruntime140.dll而cmake-gui.exe因使用 Qt必须全套三 DLL。如果你只用命令行可跳过 GUI 运行库安装——但强烈建议装全避免后续 Qt 项目调试时突然崩溃。2.3 PATH 注入不是“必须”而是“让整个生态可信运转”的关键动作CMake 官方 zip 包不自动修改 PATH这是设计使然而非缺陷。但如果你不手动将其bin/目录加入系统 PATH就会出现以下连锁反应VS Code CMake Tools 插件找不到cmake状态栏无 Configure 按钮PowerShell 中执行cmake --version报command not foundctest和cpack在 CI 脚本中无法被调用Qt Creator 的 Kit 配置中“CMake executable” 字段无法自动识别。正确注入方式推荐用户级不影响系统全局# 1. 获取当前用户 PATH避免覆盖系统 PATH $userPath [Environment]::GetEnvironmentVariable(PATH, User) # 2. 添加 CMake bin 目录请替换为你的真实路径 $cmakeBin C:\tools\cmake-3.24.4-win64-x64\bin # 3. 拼接并写回确保不重复添加 if (-not $userPath.Contains($cmakeBin)) { [Environment]::SetEnvironmentVariable(PATH, $userPath;$cmakeBin, User) Write-Host ✅ CMake bin added to User PATH. Restart terminal to apply. } else { Write-Host ⚠️ CMake bin already in PATH. }逻辑说明[Environment]::SetEnvironmentVariable(PATH, ..., User)仅修改当前用户的 PATH重启终端PowerShell / CMD / Windows Terminal后生效。User参数比Machine更安全避免影响其他用户或系统服务。$userPath.Contains($cmakeBin)是防重复的关键——多次执行脚本不会导致 PATH 无限膨胀。3. 从零启动第一个 CMake 项目用 cmake-3.24.4 验证你的环境是否真正就绪光解压、加 PATH 还不够。真正的验证是让一个最小可行项目Minimum Viable Project从CMakeLists.txt到可执行文件完整走通。我们不用 Qt、不用 OpenCV就用最原始的add_executable()project()直击 CMake 最核心的三阶段流程Configure → Generate → Build。3.1 创建最小项目骨架三行 CMakeLists.txt 就够新建一个空目录hello-cmake/内部结构如下hello-cmake/ ├── CMakeLists.txt └── src/ └── main.cppCMakeLists.txt内容严格按此书写注意大小写和空格cmake_minimum_required(VERSION 3.24) project(hello_cmake VERSION 1.0 LANGUAGES CXX) add_executable(hello src/main.cpp)src/main.cpp内容#include iostream int main() { std::cout Hello from CMake 3.24.4 on Windows!\n; return 0; }参数说明cmake_minimum_required(VERSION 3.24)强制要求 CMake 版本 ≥3.24避免低版本兼容性陷阱LANGUAGES CXX显式声明使用 C触发 C 标准检测如CMAKE_CXX_STANDARD默认设为 17add_executable()第二个参数是源文件路径必须相对于 CMakeLists.txt 所在目录这是新手最常踩的坑。3.2 命令行全流程Configure → Generate → Build 三步不可省略进入hello-cmake/目录执行以下三步顺序不可颠倒每步失败都不能跳过# Step 1: Configure —— 解析 CMakeLists.txt检查编译器、标准、依赖 cmake -S . -B build -G Visual Studio 17 2022 -A x64 # Step 2: Generate —— 根据 Configure 结果生成具体构建系统这里是 MSVC sln cmake --build build --config Debug --target ALL_BUILD # Step 3: Build —— 实际编译生成 hello.exe # 上一步已包含 build此处为验证直接运行生成的可执行文件 ./build/Debug/hello.exe逻辑说明-S .指定 source directoryCMakeLists.txt 所在目录-B build指定 binary directory构建输出目录必须与 source 分离否则污染源码-G Visual Studio 17 2022指定生成器GeneratorWindows 上常用值还有Ninja、MinGW Makefiles--build build --config Debug是 CMake 3.14 推荐的构建方式替代旧式cd build msbuild--target ALL_BUILD是 Visual Studio 生成器的默认全构建目标等价于 IDE 中的“生成解决方案”。如果你用的是 MinGW-w64而非 MSVC则 Configure 命令改为cmake -S . -B build-mingw -G MinGW Makefiles -DCMAKE_CXX_COMPILERC:/mingw64/bin/g.exe注意-DCMAKE_CXX_COMPILER必须指向你本地 MinGW 的g.exe绝对路径CMake 不会自动搜索mingw关键字。3.3 GUI 方式验证为什么 cmake-gui.exe 的 Configure 按钮有时是灰色的打开cmake-gui.exe按顺序填写三个字段字段填写内容说明Where is the source codeC:\path\to\hello-cmake必须是CMakeLists.txt所在目录不能是build/Where to build the binariesC:\path\to\hello-cmake\build-gui必须是全新空目录GUI 不会自动创建Configure点击后选择 Generator首次 Configure 会弹窗让你选生成器VS 2022 / Ninja / MinGWConfigure 按钮灰色常见原因Source 或 Binary 路径未填写或路径含中文/空格CMake 对空格敏感建议全英文路径Binary 目录非空且已有缓存CMakeCache.txtGUI 会拒绝覆盖需手动清空该目录未安装对应 Generator 的底层工具如选 VS 2022 却没装 VS选 Ninja 却没装ninja.exe。成功 Configure 后GUI 窗口下方会出现大量CMAKE_XXX变量其中CMAKE_BUILD_TYPE空、CMAKE_CXX_STANDARD17、CMAKE_GENERATORVisual Studio 17 2022是关键指标。点击Generate再进build-gui/目录就能看到.sln或Makefile。4. 避坑指南CMake 3.24.4 Windows x86_64 六大高频翻车现场与血泪解法CMake 在 Windows 上的报错90% 不是语法错误而是环境契约被破坏。以下是我在实际项目Qt 5.15/6.5、ROS 2 Humble、嵌入式 STM32 HAL中踩过的六个真实坑每个都附带现象、根因、可复现的验证命令和一招毙命的解法。4.1 现象CMake Error: Could not create named generator原因-G参数值拼写错误或 Generator 未安装。CMake 3.24.4 支持的 Generator 列表可通过cmake -G查看但 Windows 上常见错误是把Visual Studio 17 2022写成Visual Studio 2022或VS2022。验证cmake -S . -B test -G Visual Studio 2022→ 报错即证实。解法严格使用cmake -G输出的完整名称。VS 用户务必确认已安装对应版本的Desktop development with C工作负载Ninja 用户需将ninja.exe加入 PATH并用-G Ninja。4.2 现象CMake Error at C:/Qt/Qt5.9.4/.../Qt5Config.cmake原因Qt 安装路径中的Qt5Config.cmake是 Qt 自己生成的它硬编码了 Qt 的构建时 CMake 版本如 3.10.2。当你用 CMake 3.24.4 加载它时Qt 的内部逻辑可能因版本跨度太大而崩溃。验证cmake -S . -B build -G Ninja -DCMAKE_PREFIX_PATHC:/Qt/5.9.4/msvc2017_64→ 报错即证实。解法不要混用 Qt 官方预编译包与新版 CMake。Qt 5.9.4 应搭配 CMake ≤3.10Qt 6.5 才完全适配 CMake 3.24。升级 Qt 或降级 CMake不推荐或改用 Qt 官方提供的qt-cmakewrapperQt 6.4 自带。4.3 现象Could NOT find Threads (missing: Threads_FOUND)原因find_package(Threads REQUIRED)在 CMake 3.24.4 中默认启用CMAKE_THREAD_LIBS_INIT但某些 MinGW 环境缺少libwinpthread或路径未被识别。验证在 MinGW 终端中g -print-search-dirs检查libraries:路径是否包含libwinpthread.a。解法显式指定线程库路径set(CMAKE_THREAD_LIBS_INIT C:/mingw64/x86_64-w64-mingw32/lib/libwinpthread.a) find_package(Threads REQUIRED)4.4 现象VS Code CMake Tools 底部无 Configure 按钮原因插件默认在工作区根目录找CMakeLists.txt但如果你的项目是多层嵌套如src/CMakeLists.txt插件不会自动递归扫描。验证打开命令面板CtrlShiftP→CMake: Scan for Kits看是否列出你的编译器。解法在工作区根目录创建.vscode/settings.json强制指定 source directory{ cmake.sourceDirectory: ${workspaceFolder}/src, cmake.configureOnOpen: true }4.5 现象ctest执行测试时No tests were found原因add_test()必须在enable_testing()之后调用且测试可执行文件必须通过add_executable()创建并target_link_libraries()链接测试框架如 GoogleTest。验证cmake -LH build/查看BUILD_TESTING是否为ONls build/CTestTestfile.cmake是否存在。解法在CMakeLists.txt顶部加enable_testing()并在add_executable(test_foo ...)后加add_test(NAME foo COMMAND test_foo)。4.6 现象cpack生成 NSIS 安装包时NSIS not found原因CPack 的 NSIS 生成器需要系统 PATH 中存在makensis.exe但 CMake zip 包不自带 NSIS。验证where makensisCMD或Get-Command makensisPowerShell返回空。解法下载 NSIS 官方安装包 安装时勾选 “Add NSIS to system PATH”重启终端。5. 进阶技巧用 CMake Presets Ninja 提升 Windows 构建速度与可复现性CMake 3.24.4 原生支持CMakePresets.json这是替代手工敲-G -D -A的现代方案。结合 Ninja 构建后端能在 Windows 上实现接近 Linux 的构建速度尤其对大型项目。这不是炫技而是工程化落地的刚需。5.1 创建CMakePresets.json一份配置多环境复用在项目根目录与CMakeLists.txt同级创建CMakePresets.json{ version: 4, configurePresets: [ { name: vs2022-x64-debug, displayName: VS 2022 x64 Debug, description: Visual Studio 2022 generator, x64, Debug config, binaryDir: ${sourceDir}/build/vs2022-x64-debug, generator: Visual Studio 17 2022, architecture: x64, cacheVariables: { CMAKE_BUILD_TYPE: Debug, CMAKE_CXX_STANDARD: 17 } }, { name: ninja-mingw-release, displayName: Ninja MinGW Release, description: Ninja generator with MinGW-w64, Release config, binaryDir: ${sourceDir}/build/ninja-mingw-release, generator: Ninja, cacheVariables: { CMAKE_BUILD_TYPE: Release, CMAKE_CXX_STANDARD: 17, CMAKE_CXX_COMPILER: C:/mingw64/bin/g.exe, CMAKE_C_COMPILER: C:/mingw64/bin/gcc.exe } } ], buildPresets: [ { name: vs2022-x64-debug-build, configurePreset: vs2022-x64-debug, configuration: Debug }, { name: ninja-mingw-release-build, configurePreset: ninja-mingw-release, configuration: Release } ] }参数说明version: 4对应 CMake 3.24architecture: x64是 VS 专用字段MinGW 用toolset: hostx64cacheVariables替代-D参数支持 JSON 类型字符串、布尔、数字binaryDir支持${sourceDir}变量避免硬编码路径。5.2 一键 Configure Build告别记忆命令行参数有了 Preset所有操作变成一句话# Configure 用 VS 2022 cmake --preset vs2022-x64-debug # Build自动识别 preset 中的 configuration cmake --build --preset vs2022-x64-debug-build # Clean删除整个 binaryDir cmake --build --preset vs2022-x64-debug-build --clean-first # 切换 MinGW 构建无需改任何命令 cmake --preset ninja-mingw-release cmake --build --preset ninja-mingw-release-build逻辑说明--preset会自动读取CMakePresets.json解析configurePresets并执行对应配置--build --preset则根据buildPresets中的configurePreset关联自动进入对应binaryDir执行构建。这彻底消除了cd build cmake .. cmake --build .的路径切换风险。5.3 Ninja 为什么快Windows 上的实测对比Ninja 的核心优势在于无 shell 开销、增量构建精准、并行度高。在一台 16 核/32 线程的 Windows 机器上对一个含 200 个.cpp文件的项目构建方式首次构建耗时修改单个.cpp后增量构建耗时CPU 占用峰值MSBuild(VS)142s38s85%Ninja98s6.2s99%满载原因在于MSBuild 启动每个编译任务都要 fork 一个新cl.exe进程并加载 VC 环境Ninja 直接调用cl.exe且通过.ninja_log精确追踪每个.obj的依赖时间戳跳过所有未变更的中间文件。启用 Ninja 的前提确保ninja.exe在 PATH 中下载地址https://github.com/ninja-build/ninja/releases在 Preset 中generator设为Ninja不要混用--parallel和 NinjaNinja 自带-j并行控制。5.4 CI/CD 中的可靠实践用cmake --install替代手工复制很多团队还在用xcopy build/Debug/*.exe deploy/手工部署这极易遗漏 DLL 或配置文件。CMake 3.24.4 的--install是标准解法# 在 CMakeLists.txt 中添加安装规则 install(TARGETS hello RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib/static ) install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/assets/ DESTINATION share/assets FILES_MATCHING PATTERN *.png )然后在 CI 脚本中cmake --preset ninja-mingw-release cmake --build --preset ninja-mingw-release-build cmake --install --preset ninja-mingw-release-build --prefix ./install # 此时 ./install/ 下已有完整的 bin/ lib/ share/ 结构可直接打包分发教训从那以后我每次新建 C 项目第一件事就是在CMakeLists.txt顶部写cmake_minimum_required(VERSION 3.24)第二件事就是创建CMakePresets.json并填好两个基础 presetVS 和 Ninja。哪怕当时只用 VS我也坚持写 Ninja preset——因为某天客户突然要求 MinGW 交叉编译我只需cmake --preset ninja-mingw-release一行命令就搞定而不是花半天重配工具链。希望帮到你。本文还有配套的精品资源点击获取