简介本资源为CMake 3.31.10版本的Windows x86_64平台安装包面向需要在64位Windows系统上进行跨平台项目构建的C/C开发者与工程团队。CMake通过平台无关的CMakeLists.txt配置本地构建环境可适配GNU Make、Visual Studio、Xcode等工具帮助开发者省去手工维护底层构建脚本的繁琐工作。压缩包共含2000个文件以1136个txt与864个html为主涵盖命令参考、变量说明、生成器表达式、预设配置及测试打包等官方文档内容整体约44.5MB解压后运行exe即可完成安装。目前已有294人学习下载。借助这批文档读者可系统查阅cmake、ctest、cmake-buildsystem等模块的用法理解构建参数与变量含义掌握测试集成与CPack打包思路从而更高效地完成跨平台项目的配置、迁移与部署。1. 拿到 cmake-3.31.10-windows-x86_64.zip 之后它到底是什么、谁该用它很多人第一次搜 cmake下载是因为在 Windows 上编译某个 C/C 项目时命令行甩出一句cmake 不是内部或外部命令。这时候你需要的不是「CMake 是什么」的科普而是一个能立刻跑起来的 Windows x86_64 版本。cmake-3.31.10-windows-x86_64.zip就是这样一个东西它是 CMake 官方为 64 位 Windows 提供的免安装压缩包解压后里面是bin、share、doc等目录bin下同时有cmake.exe、cmake-gui.exe、ctest.exe、cpack.exe。它不写注册表、不装服务解压即用特别适合公司电脑没管理员权限、或者你想同时留好几个 CMake 版本做对比的场景。这个包解决的核心问题是「构建系统生成」你写一份CMakeLists.txt它帮你生成 Visual Studio 的.sln、Ninja 的build.ninja或者 MinGW 的 Makefile然后再调用真正的编译器和链接器。所以它和 makefile 不是一回事——makefile 是「构建脚本本身」CMake 是「生成构建脚本的工具」这也是 cmake和makefile区别 被反复搜的原因。适合谁用做 C 跨平台库的、要接 Qt 的、编译第三方开源库比如 raylib、mosquitto 这类用 CMake 组织的项目的以及需要在 Windows 上复现 Linux 构建流程的人。下面按「解压 → 配环境 → 跑通第一个工程 → 排错 → 进阶」的顺序讲透。2. 解压、配 PATH 与验证把 cmake 命令真正落到终端里2.1 解压位置的选择与目录结构cmake-3.31.10-windows-x86_64.zip解压后通常长这样不同小版本目录名略有差异以你解压出来的为准cmake-3.31.10-windows-x86_64/ ├── bin/ │ ├── cmake.exe │ ├── cmake-gui.exe │ ├── ctest.exe │ ├── cpack.exe │ └── cmake.exe 依赖的一批 dll ├── doc/ ├── share/ │ ├── cmake-3.31/ │ └── ... └── ...关键点bin目录必须整体保留cmake.exe依赖同目录下的若干 dll单独把 exe 拷走会直接报缺 dll。我一般会把整个文件夹放到一个路径不含空格和中文的位置比如D:\tools\cmake-3.31.10。为什么强调不含空格因为后面配 PATH 和在某些老构建脚本里拼接路径时空格会引发一堆引号问题属于典型的血泪经验。2.2 用 setx 永久写入 PATH临时用可以在当前终端set PATHD:\tools\cmake-3.31.10\bin;%PATH%但关掉窗口就没了。永久写入用setx:: 把 CMake 的 bin 目录追加进用户级 PATH不需要管理员权限 setx PATH D:\tools\cmake-3.31.10\bin;%PATH%逻辑说明setx写的是用户环境变量只影响当前用户避免动系统级 PATH 带来的风险。参数说明第一个参数是变量名PATH第二个是值这里把新目录放在最前面保证优先命中你这份 CMake而不是机器上可能存在的旧版本。注意setx有长度限制约 1024 字符如果你的 PATH 已经很长建议先清理无用项或者改用「系统属性 → 环境变量」图形界面编辑。提示setx执行后不会影响已经打开的终端必须新开一个 cmd 或 PowerShell 才能生效。2.3 验证版本与生成器可用性新开终端后执行cmake --version cmake --helpcmake --version应输出cmake version 3.31.10。如果提示找不到命令八成是 PATH 没生效或路径写错。cmake --help会列出当前可用的生成器Generators这是判断你机器上有没有 Visual Studio、Ninja、MinGW 的关键。常见输出里会有Visual Studio 17 2022、Ninja、MinGW Makefiles等。如果你只装了 VS 但没装「使用 C 的桌面开发」工作负载生成器列表里可能看不到对应项这是后面编译失败的常见根因。2.4 用 cmake-gui 做一次可视化确认bin下的cmake-gui.exe是给不习惯命令行的人准备的。双击打开第一行填源码目录含CMakeLists.txt第二行填构建目录建议单独建build点 Configure 会让你选生成器。这一步的价值在于当你命令行报错看不懂时GUI 的报错信息往往更完整还能直接看到每个缓存变量Cache Variables的当前值。cmake gui 这个搜索词背后很多人就是卡在「不知道生成器选哪个」上。3. 跑通第一个工程从 CMakeLists.txt 到可执行文件3.1 最小 CMakeLists.txt 与构建流程建一个目录hello里面放main.cpp和CMakeLists.txt// main.cpp #include iostream int main() { std::cout cmake ok std::endl; return 0; }# CMakeLists.txt cmake_minimum_required(VERSION 3.31) # 声明最低要求的 CMake 版本 project(hello LANGUAGES CXX) # 工程名与语言 add_executable(hello main.cpp) # 生成名为 hello 的可执行文件然后在hello目录下执行标准的 out-of-source 构建cmake -S . -B build -G Visual Studio 17 2022 -A x86_64 cmake --build build --config Release逻辑说明-S .指定源码目录为当前目录-B build指定构建目录为build这样所有中间产物都进build源码目录保持干净。-G指定生成器-A x86_64指定目标架构为 64 位和标题里的 x86_64 对应。第二条cmake --build是跨生成器的统一构建命令不用管底层是 msbuild 还是 ninja。参数说明--config Release对多配置生成器VS有效单配置生成器Ninja、Makefiles在配置阶段就要用-DCMAKE_BUILD_TYPERelease指定。3.2 换 Ninja 生成器更快、更适合脚本化如果你装了 Ninja可以换成cmake -S . -B build-ninja -G Ninja -DCMAKE_BUILD_TYPERelease cmake --build build-ninjaNinja 的优势是增量构建快、输出干净适合放进 CI 或批处理脚本。注意CMAKE_BUILD_TYPE只在单配置生成器下有意义VS 生成器下写了也会被忽略这是新手最容易困惑的点之一。构建产物位置也不同VS 在build/Release/hello.exeNinja 在build-ninja/hello.exe。3.3 指定编译器与工具链Windows 上 CMake 找编译器靠生成器推断。如果你想用 MinGW 的 g可以cmake -S . -B build-mingw -G MinGW Makefiles ^ -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERg参数说明CMAKE_C_COMPILER和CMAKE_CXX_COMPILER显式指定编译器路径避免 CMake 猜错。注意这些变量只在首次配置时生效改了要删掉build目录里的CMakeCache.txt重新配置否则 CMake 会继续用缓存里的旧编译器——这是「改了配置没反应」的头号原因。3.4 用 ctest 跑测试CMake 自带测试框架入口。在CMakeLists.txt里加enable_testing() add_test(NAME run_hello COMMAND hello)然后ctest --test-dir build -C Release --output-on-failure--output-on-failure让测试失败时打印输出-C Release对多配置生成器指定配置。这一步在接 CI 时非常有用能把「编译过了」升级成「行为正确」。4. 避坑与排查Windows 上 CMake 最常见的 5 个翻车现场4.1 报错「CMake Error: Could not create named generator」现象执行cmake -G Visual Studio 17 2022时提示找不到生成器。原因机器上没装对应版本的 Visual Studio或者装了但没勾选 C 工作负载CMake 探测不到。解决先跑cmake --help看可用生成器列表装齐 VS 的「使用 C 的桌面开发」实在不想装 VS就改用 Ninja 或 MinGW Makefiles。4.2 改了 CMakeLists.txt 但构建结果没变现象明明改了源码或配置cmake --build却像没看见。原因CMake 的缓存CMakeCache.txt记住了上次的配置某些变量改动不会自动触发重配。解决删掉整个build目录重新配置这是最省事的后悔药或者用cmake --fresh -S . -B build较新版本支持强制刷新缓存。4.3 路径含空格或中文导致诡异失败现象配置阶段报找不到文件或链接阶段路径被截断。原因部分生成器和底层工具对含空格、中文的路径处理不干净。解决把源码和构建目录都放在纯英文、无空格的路径下比如D:\work\proj。这是最容易被忽视、又最难排查的一类问题。4.4 找不到第三方库如 Qt、raylib现象find_package(Qt6)或find_package(raylib)报 not found。原因库没装或装了但 CMake 不知道去哪找。解决用-DCMAKE_PREFIX_PATHD:\path\to\lib告诉 CMake 搜索前缀对 Qt 这类通常要指向lib/cmake的上级目录。raylib cmake 场景下如果用的是预编译包确认它带不带raylib-config.cmake没有的话就得用FetchContent或手动target_link_libraries指定.lib路径。4.5 多配置生成器下找不到 exe现象cmake --build build成功但在build根目录找不到 exe。原因VS 这类多配置生成器会把产物放进build/Release或build/Debug子目录。解决要么去对应子目录找要么用cmake --install配合CMAKE_INSTALL_PREFIX统一输出位置要么干脆换 Ninja 这种单配置生成器。5. 进阶把 CMake 用成可复现的构建流水线5.1 用 CMakePresets.json 固化参数每次敲一长串-G、-A、-D很容易记错。CMake 3.19 之后支持CMakePresets.json把配置写进文件{ version: 3, configurePresets: [ { name: vs-x64-release, generator: Visual Studio 17 2022, architecture: x86_64, binaryDir: ${sourceDir}/build/vs-x64, cacheVariables: { CMAKE_BUILD_TYPE: Release } }, { name: ninja-release, generator: Ninja, binaryDir: ${sourceDir}/build/ninja, cacheVariables: { CMAKE_BUILD_TYPE: Release } } ] }之后只需cmake --preset vs-x64-release cmake --build --preset vs-x64-release逻辑说明binaryDir用${sourceDir}变量保证相对路径可移植cacheVariables把构建类型固化。参数说明version字段要和你的 CMake 版本兼容3.31 支持 version 3 及以上。这样团队里每个人拉下代码就能用同一套参数构建避免「我这能编你那不能编」的玄学。5.2 用 FetchContent 拉取依赖不想手动装第三方库时可以在CMakeLists.txt里直接拉include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG v1.14.0 ) FetchContent_MakeAvailable(googletest)逻辑说明FetchContent_Declare声明依赖来源FetchContent_MakeAvailable在配置阶段下载并加入构建。参数说明GIT_TAG建议锁到具体 tag 而不是分支保证可复现。注意首次配置需要网络内网环境要提前配好镜像或改用本地路径。5.3 验证构建是否真的可复现一个实用技巧连续两次从干净目录构建对比产物哈希。Windows 下可以用certutil -hashfile hello.exe SHA256看哈希。如果两次不一致通常是嵌入了时间戳或路径信息可以用-DCMAKE_BUILD_RPATH_USE_ORIGINON之类的选项排查。这一步能帮你确认构建流水线是否稳定也是接 CI 前的必要检查。我自己踩过最深的一次是在一台没管理员权限的机器上折腾了半天 PATH最后发现只要把bin目录整个拷到项目里、用相对路径调用就绕过去了。从那以后我养成了一个习惯拿到任何免安装压缩包先确认它依赖哪些同目录文件再决定怎么配环境而不是急着往 PATH 里塞。希望帮到你。本文还有配套的精品资源点击获取
简介本资源为CMake 3.31.10版本的Windows x86_64平台安装包面向需要在64位Windows系统上进行跨平台项目构建的C/C开发者与工程团队。CMake通过平台无关的CMakeLists.txt配置本地构建环境可适配GNU Make、Visual Studio、Xcode等工具帮助开发者省去手工维护底层构建脚本的繁琐工作。压缩包共含2000个文件以1136个txt与864个html为主涵盖命令参考、变量说明、生成器表达式、预设配置及测试打包等官方文档内容整体约44.5MB解压后运行exe即可完成安装。目前已有294人学习下载。借助这批文档读者可系统查阅cmake、ctest、cmake-buildsystem等模块的用法理解构建参数与变量含义掌握测试集成与CPack打包思路从而更高效地完成跨平台项目的配置、迁移与部署。1. 拿到 cmake-3.31.10-windows-x86_64.zip 之后它到底是什么、谁该用它很多人第一次搜 cmake下载是因为在 Windows 上编译某个 C/C 项目时命令行甩出一句cmake 不是内部或外部命令。这时候你需要的不是「CMake 是什么」的科普而是一个能立刻跑起来的 Windows x86_64 版本。cmake-3.31.10-windows-x86_64.zip就是这样一个东西它是 CMake 官方为 64 位 Windows 提供的免安装压缩包解压后里面是bin、share、doc等目录bin下同时有cmake.exe、cmake-gui.exe、ctest.exe、cpack.exe。它不写注册表、不装服务解压即用特别适合公司电脑没管理员权限、或者你想同时留好几个 CMake 版本做对比的场景。这个包解决的核心问题是「构建系统生成」你写一份CMakeLists.txt它帮你生成 Visual Studio 的.sln、Ninja 的build.ninja或者 MinGW 的 Makefile然后再调用真正的编译器和链接器。所以它和 makefile 不是一回事——makefile 是「构建脚本本身」CMake 是「生成构建脚本的工具」这也是 cmake和makefile区别 被反复搜的原因。适合谁用做 C 跨平台库的、要接 Qt 的、编译第三方开源库比如 raylib、mosquitto 这类用 CMake 组织的项目的以及需要在 Windows 上复现 Linux 构建流程的人。下面按「解压 → 配环境 → 跑通第一个工程 → 排错 → 进阶」的顺序讲透。2. 解压、配 PATH 与验证把 cmake 命令真正落到终端里2.1 解压位置的选择与目录结构cmake-3.31.10-windows-x86_64.zip解压后通常长这样不同小版本目录名略有差异以你解压出来的为准cmake-3.31.10-windows-x86_64/ ├── bin/ │ ├── cmake.exe │ ├── cmake-gui.exe │ ├── ctest.exe │ ├── cpack.exe │ └── cmake.exe 依赖的一批 dll ├── doc/ ├── share/ │ ├── cmake-3.31/ │ └── ... └── ...关键点bin目录必须整体保留cmake.exe依赖同目录下的若干 dll单独把 exe 拷走会直接报缺 dll。我一般会把整个文件夹放到一个路径不含空格和中文的位置比如D:\tools\cmake-3.31.10。为什么强调不含空格因为后面配 PATH 和在某些老构建脚本里拼接路径时空格会引发一堆引号问题属于典型的血泪经验。2.2 用 setx 永久写入 PATH临时用可以在当前终端set PATHD:\tools\cmake-3.31.10\bin;%PATH%但关掉窗口就没了。永久写入用setx:: 把 CMake 的 bin 目录追加进用户级 PATH不需要管理员权限 setx PATH D:\tools\cmake-3.31.10\bin;%PATH%逻辑说明setx写的是用户环境变量只影响当前用户避免动系统级 PATH 带来的风险。参数说明第一个参数是变量名PATH第二个是值这里把新目录放在最前面保证优先命中你这份 CMake而不是机器上可能存在的旧版本。注意setx有长度限制约 1024 字符如果你的 PATH 已经很长建议先清理无用项或者改用「系统属性 → 环境变量」图形界面编辑。提示setx执行后不会影响已经打开的终端必须新开一个 cmd 或 PowerShell 才能生效。2.3 验证版本与生成器可用性新开终端后执行cmake --version cmake --helpcmake --version应输出cmake version 3.31.10。如果提示找不到命令八成是 PATH 没生效或路径写错。cmake --help会列出当前可用的生成器Generators这是判断你机器上有没有 Visual Studio、Ninja、MinGW 的关键。常见输出里会有Visual Studio 17 2022、Ninja、MinGW Makefiles等。如果你只装了 VS 但没装「使用 C 的桌面开发」工作负载生成器列表里可能看不到对应项这是后面编译失败的常见根因。2.4 用 cmake-gui 做一次可视化确认bin下的cmake-gui.exe是给不习惯命令行的人准备的。双击打开第一行填源码目录含CMakeLists.txt第二行填构建目录建议单独建build点 Configure 会让你选生成器。这一步的价值在于当你命令行报错看不懂时GUI 的报错信息往往更完整还能直接看到每个缓存变量Cache Variables的当前值。cmake gui 这个搜索词背后很多人就是卡在「不知道生成器选哪个」上。3. 跑通第一个工程从 CMakeLists.txt 到可执行文件3.1 最小 CMakeLists.txt 与构建流程建一个目录hello里面放main.cpp和CMakeLists.txt// main.cpp #include iostream int main() { std::cout cmake ok std::endl; return 0; }# CMakeLists.txt cmake_minimum_required(VERSION 3.31) # 声明最低要求的 CMake 版本 project(hello LANGUAGES CXX) # 工程名与语言 add_executable(hello main.cpp) # 生成名为 hello 的可执行文件然后在hello目录下执行标准的 out-of-source 构建cmake -S . -B build -G Visual Studio 17 2022 -A x86_64 cmake --build build --config Release逻辑说明-S .指定源码目录为当前目录-B build指定构建目录为build这样所有中间产物都进build源码目录保持干净。-G指定生成器-A x86_64指定目标架构为 64 位和标题里的 x86_64 对应。第二条cmake --build是跨生成器的统一构建命令不用管底层是 msbuild 还是 ninja。参数说明--config Release对多配置生成器VS有效单配置生成器Ninja、Makefiles在配置阶段就要用-DCMAKE_BUILD_TYPERelease指定。3.2 换 Ninja 生成器更快、更适合脚本化如果你装了 Ninja可以换成cmake -S . -B build-ninja -G Ninja -DCMAKE_BUILD_TYPERelease cmake --build build-ninjaNinja 的优势是增量构建快、输出干净适合放进 CI 或批处理脚本。注意CMAKE_BUILD_TYPE只在单配置生成器下有意义VS 生成器下写了也会被忽略这是新手最容易困惑的点之一。构建产物位置也不同VS 在build/Release/hello.exeNinja 在build-ninja/hello.exe。3.3 指定编译器与工具链Windows 上 CMake 找编译器靠生成器推断。如果你想用 MinGW 的 g可以cmake -S . -B build-mingw -G MinGW Makefiles ^ -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERg参数说明CMAKE_C_COMPILER和CMAKE_CXX_COMPILER显式指定编译器路径避免 CMake 猜错。注意这些变量只在首次配置时生效改了要删掉build目录里的CMakeCache.txt重新配置否则 CMake 会继续用缓存里的旧编译器——这是「改了配置没反应」的头号原因。3.4 用 ctest 跑测试CMake 自带测试框架入口。在CMakeLists.txt里加enable_testing() add_test(NAME run_hello COMMAND hello)然后ctest --test-dir build -C Release --output-on-failure--output-on-failure让测试失败时打印输出-C Release对多配置生成器指定配置。这一步在接 CI 时非常有用能把「编译过了」升级成「行为正确」。4. 避坑与排查Windows 上 CMake 最常见的 5 个翻车现场4.1 报错「CMake Error: Could not create named generator」现象执行cmake -G Visual Studio 17 2022时提示找不到生成器。原因机器上没装对应版本的 Visual Studio或者装了但没勾选 C 工作负载CMake 探测不到。解决先跑cmake --help看可用生成器列表装齐 VS 的「使用 C 的桌面开发」实在不想装 VS就改用 Ninja 或 MinGW Makefiles。4.2 改了 CMakeLists.txt 但构建结果没变现象明明改了源码或配置cmake --build却像没看见。原因CMake 的缓存CMakeCache.txt记住了上次的配置某些变量改动不会自动触发重配。解决删掉整个build目录重新配置这是最省事的后悔药或者用cmake --fresh -S . -B build较新版本支持强制刷新缓存。4.3 路径含空格或中文导致诡异失败现象配置阶段报找不到文件或链接阶段路径被截断。原因部分生成器和底层工具对含空格、中文的路径处理不干净。解决把源码和构建目录都放在纯英文、无空格的路径下比如D:\work\proj。这是最容易被忽视、又最难排查的一类问题。4.4 找不到第三方库如 Qt、raylib现象find_package(Qt6)或find_package(raylib)报 not found。原因库没装或装了但 CMake 不知道去哪找。解决用-DCMAKE_PREFIX_PATHD:\path\to\lib告诉 CMake 搜索前缀对 Qt 这类通常要指向lib/cmake的上级目录。raylib cmake 场景下如果用的是预编译包确认它带不带raylib-config.cmake没有的话就得用FetchContent或手动target_link_libraries指定.lib路径。4.5 多配置生成器下找不到 exe现象cmake --build build成功但在build根目录找不到 exe。原因VS 这类多配置生成器会把产物放进build/Release或build/Debug子目录。解决要么去对应子目录找要么用cmake --install配合CMAKE_INSTALL_PREFIX统一输出位置要么干脆换 Ninja 这种单配置生成器。5. 进阶把 CMake 用成可复现的构建流水线5.1 用 CMakePresets.json 固化参数每次敲一长串-G、-A、-D很容易记错。CMake 3.19 之后支持CMakePresets.json把配置写进文件{ version: 3, configurePresets: [ { name: vs-x64-release, generator: Visual Studio 17 2022, architecture: x86_64, binaryDir: ${sourceDir}/build/vs-x64, cacheVariables: { CMAKE_BUILD_TYPE: Release } }, { name: ninja-release, generator: Ninja, binaryDir: ${sourceDir}/build/ninja, cacheVariables: { CMAKE_BUILD_TYPE: Release } } ] }之后只需cmake --preset vs-x64-release cmake --build --preset vs-x64-release逻辑说明binaryDir用${sourceDir}变量保证相对路径可移植cacheVariables把构建类型固化。参数说明version字段要和你的 CMake 版本兼容3.31 支持 version 3 及以上。这样团队里每个人拉下代码就能用同一套参数构建避免「我这能编你那不能编」的玄学。5.2 用 FetchContent 拉取依赖不想手动装第三方库时可以在CMakeLists.txt里直接拉include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG v1.14.0 ) FetchContent_MakeAvailable(googletest)逻辑说明FetchContent_Declare声明依赖来源FetchContent_MakeAvailable在配置阶段下载并加入构建。参数说明GIT_TAG建议锁到具体 tag 而不是分支保证可复现。注意首次配置需要网络内网环境要提前配好镜像或改用本地路径。5.3 验证构建是否真的可复现一个实用技巧连续两次从干净目录构建对比产物哈希。Windows 下可以用certutil -hashfile hello.exe SHA256看哈希。如果两次不一致通常是嵌入了时间戳或路径信息可以用-DCMAKE_BUILD_RPATH_USE_ORIGINON之类的选项排查。这一步能帮你确认构建流水线是否稳定也是接 CI 前的必要检查。我自己踩过最深的一次是在一台没管理员权限的机器上折腾了半天 PATH最后发现只要把bin目录整个拷到项目里、用相对路径调用就绕过去了。从那以后我养成了一个习惯拿到任何免安装压缩包先确认它依赖哪些同目录文件再决定怎么配环境而不是急着往 PATH 里塞。希望帮到你。本文还有配套的精品资源点击获取
