简介本资源为 CMake 3.24.4 版本的官方 Windows x86_64 安装包面向使用 Visual Studio、MinGW 或 Ninja 构建 C/C 项目的开发者、高校计算机课程实践者及嵌入式软件工程师解决跨平台项目配置、构建脚本编写与自动化编译环境搭建等核心问题。压缩包共含 2000 个文件以 1209 个文本文档含配置模板、变量说明、命令语法详解和 791 个 HTML 格式帮助页面涵盖 cmake、ctest、cmake-file-api、cmake-presets、生成器表达式等关键子系统为主总大小 38.24MB结构完整、离线可用无需联网即可查阅全部官方文档。已有 461 人学习下载内容覆盖构建系统原理、变量与属性机制、预设配置规范、测试框架集成及 RPM 打包支持等高阶主题HTML 页面具备完整索引与交叉链接适合从入门配置到深度定制的全流程参考。1. 从文件名到开发环境CMake 3.24.4 for Windows x86_64 的深度解析如果你在Windows上搞C/C开发或者需要编译一些开源项目那么“cmake-3.24.4-windows-x86_64.zip”这个文件名对你来说一定不陌生。它看起来就是一个普通的压缩包一个构建工具。但在我十多年的开发经历里CMake远不止是一个“构建工具”那么简单它更像是一个项目架构师和跨平台协调员。今天我们不聊那些高深的CMakeLists.txt语法就从你手头这个具体的、名为“cmake-3.24.4-windows-x86_64.zip”的文件开始把它掰开揉碎了讲清楚它是什么、为什么是它、怎么用它以及在Windows这个特定环境下你会遇到哪些坑又该如何优雅地跨过去。你会发现处理好这一个文件就能为你打通从源码到可执行程序的“任督二脉”。这个压缩包是CMake官方为64位Windows系统预编译好的独立发行版。版本号3.24.4意味着它是一个功能稳定、修复了若干已知问题的发布版本。选择它而不是最新的3.28或更老的3.16往往是在追求稳定性和特定功能支持之间的平衡。而“x86_64”则明确告诉你这是为现代64位Windows准备的它能更好地利用大内存编译大型项目时优势明显。接下来我会带你一步步拆解这个包从最基础的安装配置到解决那些让人头疼的“Visual Studio版本不匹配”、“路径乱码”等问题最后再聊聊如何用它真正提升你的开发效率。2. 解压即用没那么简单CMake Windows版的安装与系统集成很多人觉得下载一个zip包解压到某个文件夹然后双击里面的cmake-gui.exe或者从命令行运行bin\cmake.exe就能用了。理论上没错但这只是“能用”离“好用”和“团队协作友好”还差得远。一个专业的开发环境搭建必须考虑可维护性和可重复性。2.1 安装路径的选择与考量首先解压路径有讲究。不建议放在C:\Users\你的用户名\Downloads或者桌面这种临时位置。我推荐两个方案集中管理方案在非系统盘如D盘创建一个专门的开发工具目录例如D:\DevTools。然后将cmake-3.24.4-windows-x86_64文件夹解压到此并可以考虑重命名为D:\DevTools\CMake-3.24.4。这样做的好处是所有工具路径清晰便于备份和迁移。绿色便携方案如果你需要经常在多台机器或虚拟机上部署可以将整个CMake目录放在项目仓库的tools/目录下或者使用像Scoop、Chocolatey这样的Windows包管理器进行安装它们能更好地处理版本管理和环境变量。以方案一为例你解压后的目录结构应该是这样的D:\DevTools\CMake-3.24.4\ ├── bin\ # 核心可执行文件cmake.exe, ctest.exe, cpack.exe 就在这里 ├── doc\ # 帮助文档 ├── man\ # Unix风格的手册页在Windows上用处不大 └── share\ # 模块文件、模板等关键就在这个bin文件夹里面的cmake.exe是我们一切操作的基础。2.2 环境变量配置让命令行认识CMake解压完直接运行bin\cmake.exe是可以的但每次都要输入完整路径太麻烦。我们需要将D:\DevTools\CMake-3.24.4\bin添加到系统的PATH环境变量中。操作步骤与原理在Windows搜索栏输入“环境变量”选择“编辑系统环境变量”。点击“环境变量”按钮。在“系统变量”区域找到并选中Path变量点击“编辑”。点击“新建”然后将你的CMake的bin目录完整路径如D:\DevTools\CMake-3.24.4\bin添加进去。重要确保你添加的是bin目录而不是CMake的根目录。因为操作系统是通过PATH来查找可执行文件的它只会遍历PATH中每个目录下的文件。配置完成后重新启动任何一个命令行终端CMD或PowerShell。这是必须的因为只有新启动的进程才会读取新的环境变量。然后输入cmake --version如果看到类似“cmake version 3.24.4”的输出恭喜你CMake已经成功集成到你的系统了。这一步看似简单但很多后续问题比如在VSCode中CMake找不到的根源都出在这里。2.3 验证安装与多版本共存有时候你的系统里可能已经存在其他版本的CMake比如通过Visual Studio Installer安装的。你可以通过命令行查看所有CMake的路径where cmake这个命令会列出所有在PATH中找到的cmake.exe路径。排在第一位的将被优先使用。如果你需要切换版本只需调整PATH中路径的顺序即可。注意有些集成开发环境IDE如CLion、Qt Creator有自己内置的CMake查找逻辑可能优先使用其绑定的版本。通常可以在IDE的设置中手动指定CMake路径指向我们刚刚安装的bin\cmake.exe以获得一致的构建行为。3. 核心实战使用CMake配置与生成Visual Studio项目安装配置好之后我们进入实战环节。网络上很多“cmake error: generator : visual studio 16 2019 does not match”的错误其根源就在于对CMake“生成器Generator”的理解不透彻。我们就从这个高频错误入手。3.1 理解“生成器Generator”与你的Visual StudioCMake本身不编译代码它是一个“项目生成器”。它的工作是将你写的CMakeLists.txt转换成特定编译器/构建系统能理解的项目文件。在Windows上这个构建系统通常是Visual Studio的MSBuild或者Ninja。cmake-3.24.4-windows-x86_64.zip这个包是“纯净”的CMake它不包含任何编译器。它需要知道你系统里装了什么编译器才能为其生成项目文件。这就是“生成器”的作用。当你运行cmake .时CMake会自动检测系统环境选择一个它认为合适的生成器。但自动检测常常出问题尤其是当你安装了多个版本的Visual Studio时。所以显式指定生成器是最佳实践。如何查看和指定生成器在命令行中进入你的项目源码目录假设该目录下已有CMakeLists.txt先创建一个用于构建的目录这叫做“Out-of-Source Build”是好习惯能保持源码目录清洁mkdir build cd build然后使用-G参数指定生成器。要查看当前CMake支持哪些生成器可以运行cmake -G对于Visual Studio 2019你应该看到类似“Visual Studio 16 2019”的选项。那么完整的配置命令就是cmake .. -G Visual Studio 16 2019 -A x64这里..表示CMakeLists.txt在上一级目录。-G Visual Studio 16 2019明确告诉CMake“请为VS2019生成解决方案”。-A x64指定目标平台为64位x86_64。这是关键如果你省略了-A默认可能会生成Win3232位的项目这与你x86_64的CMake和64位系统可能不匹配导致后续编译出现各种奇怪问题。3.2 解决“Generator不匹配”错误现在我们来解剖那个经典错误cmake error: error: generator : visual studio 16 2019 does not match the generator used previously。这个错误通常发生在你多次运行cmake命令但使用了不同的生成器或参数。CMake会在构建目录本例中的build下生成一个CMakeCache.txt文件它缓存了第一次配置时的所有参数包括生成器。错误场景复现第一次你在build目录下执行了cmake ..没有指定-G和-ACMake可能自动选择了“Visual Studio 16 2019”但平台是Win32并写入了缓存。第二次你想生成64位项目执行了cmake .. -G “Visual Studio 16 2019” -A x64。CMake检查缓存发现生成器信息虽然名字一样但缓存里可能隐含了平台信息不一致于是报错。根治方案 最彻底的办法是清空构建目录重新开始。因为CMakeCache.txt是问题的根源。# 在项目根目录下 rmdir /s /q build # 删除旧的build目录 mkdir build cd build cmake .. -G “Visual Studio 16 2019” -A x64 # 使用完整、正确的参数重新配置养成“为每个不同的配置创建独立的构建目录”的习惯比如build_vs2019_x64build_ninja_debug可以从根本上避免这类缓存冲突。3.3 生成后的操作编译与安装配置成功后你的build目录下会生成一个YourProject.sln文件。你可以用两种方式编译命令行编译推荐便于自动化# 仍在build目录下 cmake --build . --config Release这个命令是跨平台的它调用了底层生成器这里是MSBuild来执行编译。--config Release指定构建“Release”配置。你也可以换成Debug。IDE打开直接用Visual Studio 2019打开YourProject.sln文件像普通项目一样进行编译和调试。如果需要安装将编译好的头文件、库文件复制到指定目录如CMAKE_INSTALL_PREFIX可以在命令行使用cmake --build . --config Release --target install或者在Visual Studio中生成INSTALL项目。4. 避坑指南Windows下的路径、编码与工具链陷阱在Windows上用CMake除了生成器还有几个“特色”坑点需要特别注意。4.1 路径中的空格与中文CMake源于Unix世界对路径中的空格比较敏感。虽然现代CMake处理得已经好很多但依然建议将CMake安装在无空格、无中文的路径下。这就是为什么我推荐D:\DevTools而不是C:\Program Files。Program Files中间的空格在某些极端情况下比如在命令行参数中传递路径时如果引号处理不当可能引发问题。项目源码路径也遵循此原则。避免把项目放在桌面或我的文档这类可能包含中文或空格的目录下。使用纯英文、无空格的路径如D:\Projects\my_cmake_project能省去很多不必要的麻烦。4.2 文件编码与脚本执行“windows乱码的乱码大全”这个热搜词背后是Windows默认编码GBK与开源世界主流编码UTF-8的冲突。这会影响CMakeLists.txt中的注释、字符串以及CMake执行过程中输出的信息。解决方案编辑器设置确保你的代码编辑器如VSCode、Notepad、Sublime Text将CMakeLists.txt以及所有.cpp、.h文件以UTF-8 without BOM的编码格式保存。在VSCode中右下角可以点击切换编码。PowerShell/CMD编码在中文Windows上CMD默认是GBKPowerShell的默认编码可能随版本变化。如果你在脚本中输出或处理中文可能会乱码。对于CMake构建本身只要源文件是UTF-8通常问题不大。但如果需要在构建前后执行自定义脚本需要注意编码转换。一个治本的方法是使用Windows Terminal并将其默认配置文件中的编码设置为UTF-8。4.3 与其他工具链的协作Cygwin、MinGW、WSL从热搜词cygwin cmake和适用于 linux 的 windows 子系统可以看出很多开发者是在混合环境下工作。Cygwin/MinGW这些是Windows上的POSIX兼容层或GNU工具链。如果你需要为它们构建项目在运行CMake时需要指定对应的生成器例如-G “MinGW Makefiles”。并且你需要确保gcc、g、make等工具已在PATH中且顺序正确在MSVC工具链之前。通常更推荐使用独立的mingw64发行版并将其bin目录加入PATH前端。WSLWindows Subsystem for Linux这是更彻底的方案。你可以在WSL的Ubuntu中直接使用apt-get install cmake安装的CMake然后在Linux环境下进行纯正的GNU/Linux构建。此时cmake-3.24.4-windows-x86_64.zip这个Windows原生版本就用不上了。两者是完全独立的环境。如果你在Windows文件资源管理器中操作WSL下的文件需要注意文件系统权限和行尾符CRLF vs LF可能带来的问题。4.4 依赖管理find_package的挑战在Linux上库文件通常安装在标准路径如/usr/libfind_package很容易找到。在Windows上第三方库可能散落在任何地方。你需要通过设置CMAKE_PREFIX_PATH变量来告诉CMake去哪里找。例如如果你将OpenCV安装在D:\DevTools\opencv那么在CMake配置时可以这样做cmake .. -G “Visual Studio 16 2019” -A x64 -DCMAKE_PREFIX_PATHD:\DevTools\opencv\build或者在CMakeLists.txt中在find_package(OpenCV REQUIRED)之前使用set(CMAKE_PREFIX_PATH “D:/DevTools/opencv/build”)。对于没有提供CMake配置文件的库你可能需要手动指定XXX_INCLUDE_DIR和XXX_LIBRARY变量这是一个更繁琐但Windows C开发中无法回避的过程。本文还有配套的精品资源点击获取 CMake 3.24.4 Windows版深度解析：从安装配置到Visual Studio项目生成实战
简介本资源为 CMake 3.24.4 版本的官方 Windows x86_64 安装包面向使用 Visual Studio、MinGW 或 Ninja 构建 C/C 项目的开发者、高校计算机课程实践者及嵌入式软件工程师解决跨平台项目配置、构建脚本编写与自动化编译环境搭建等核心问题。压缩包共含 2000 个文件以 1209 个文本文档含配置模板、变量说明、命令语法详解和 791 个 HTML 格式帮助页面涵盖 cmake、ctest、cmake-file-api、cmake-presets、生成器表达式等关键子系统为主总大小 38.24MB结构完整、离线可用无需联网即可查阅全部官方文档。已有 461 人学习下载内容覆盖构建系统原理、变量与属性机制、预设配置规范、测试框架集成及 RPM 打包支持等高阶主题HTML 页面具备完整索引与交叉链接适合从入门配置到深度定制的全流程参考。1. 从文件名到开发环境CMake 3.24.4 for Windows x86_64 的深度解析如果你在Windows上搞C/C开发或者需要编译一些开源项目那么“cmake-3.24.4-windows-x86_64.zip”这个文件名对你来说一定不陌生。它看起来就是一个普通的压缩包一个构建工具。但在我十多年的开发经历里CMake远不止是一个“构建工具”那么简单它更像是一个项目架构师和跨平台协调员。今天我们不聊那些高深的CMakeLists.txt语法就从你手头这个具体的、名为“cmake-3.24.4-windows-x86_64.zip”的文件开始把它掰开揉碎了讲清楚它是什么、为什么是它、怎么用它以及在Windows这个特定环境下你会遇到哪些坑又该如何优雅地跨过去。你会发现处理好这一个文件就能为你打通从源码到可执行程序的“任督二脉”。这个压缩包是CMake官方为64位Windows系统预编译好的独立发行版。版本号3.24.4意味着它是一个功能稳定、修复了若干已知问题的发布版本。选择它而不是最新的3.28或更老的3.16往往是在追求稳定性和特定功能支持之间的平衡。而“x86_64”则明确告诉你这是为现代64位Windows准备的它能更好地利用大内存编译大型项目时优势明显。接下来我会带你一步步拆解这个包从最基础的安装配置到解决那些让人头疼的“Visual Studio版本不匹配”、“路径乱码”等问题最后再聊聊如何用它真正提升你的开发效率。2. 解压即用没那么简单CMake Windows版的安装与系统集成很多人觉得下载一个zip包解压到某个文件夹然后双击里面的cmake-gui.exe或者从命令行运行bin\cmake.exe就能用了。理论上没错但这只是“能用”离“好用”和“团队协作友好”还差得远。一个专业的开发环境搭建必须考虑可维护性和可重复性。2.1 安装路径的选择与考量首先解压路径有讲究。不建议放在C:\Users\你的用户名\Downloads或者桌面这种临时位置。我推荐两个方案集中管理方案在非系统盘如D盘创建一个专门的开发工具目录例如D:\DevTools。然后将cmake-3.24.4-windows-x86_64文件夹解压到此并可以考虑重命名为D:\DevTools\CMake-3.24.4。这样做的好处是所有工具路径清晰便于备份和迁移。绿色便携方案如果你需要经常在多台机器或虚拟机上部署可以将整个CMake目录放在项目仓库的tools/目录下或者使用像Scoop、Chocolatey这样的Windows包管理器进行安装它们能更好地处理版本管理和环境变量。以方案一为例你解压后的目录结构应该是这样的D:\DevTools\CMake-3.24.4\ ├── bin\ # 核心可执行文件cmake.exe, ctest.exe, cpack.exe 就在这里 ├── doc\ # 帮助文档 ├── man\ # Unix风格的手册页在Windows上用处不大 └── share\ # 模块文件、模板等关键就在这个bin文件夹里面的cmake.exe是我们一切操作的基础。2.2 环境变量配置让命令行认识CMake解压完直接运行bin\cmake.exe是可以的但每次都要输入完整路径太麻烦。我们需要将D:\DevTools\CMake-3.24.4\bin添加到系统的PATH环境变量中。操作步骤与原理在Windows搜索栏输入“环境变量”选择“编辑系统环境变量”。点击“环境变量”按钮。在“系统变量”区域找到并选中Path变量点击“编辑”。点击“新建”然后将你的CMake的bin目录完整路径如D:\DevTools\CMake-3.24.4\bin添加进去。重要确保你添加的是bin目录而不是CMake的根目录。因为操作系统是通过PATH来查找可执行文件的它只会遍历PATH中每个目录下的文件。配置完成后重新启动任何一个命令行终端CMD或PowerShell。这是必须的因为只有新启动的进程才会读取新的环境变量。然后输入cmake --version如果看到类似“cmake version 3.24.4”的输出恭喜你CMake已经成功集成到你的系统了。这一步看似简单但很多后续问题比如在VSCode中CMake找不到的根源都出在这里。2.3 验证安装与多版本共存有时候你的系统里可能已经存在其他版本的CMake比如通过Visual Studio Installer安装的。你可以通过命令行查看所有CMake的路径where cmake这个命令会列出所有在PATH中找到的cmake.exe路径。排在第一位的将被优先使用。如果你需要切换版本只需调整PATH中路径的顺序即可。注意有些集成开发环境IDE如CLion、Qt Creator有自己内置的CMake查找逻辑可能优先使用其绑定的版本。通常可以在IDE的设置中手动指定CMake路径指向我们刚刚安装的bin\cmake.exe以获得一致的构建行为。3. 核心实战使用CMake配置与生成Visual Studio项目安装配置好之后我们进入实战环节。网络上很多“cmake error: generator : visual studio 16 2019 does not match”的错误其根源就在于对CMake“生成器Generator”的理解不透彻。我们就从这个高频错误入手。3.1 理解“生成器Generator”与你的Visual StudioCMake本身不编译代码它是一个“项目生成器”。它的工作是将你写的CMakeLists.txt转换成特定编译器/构建系统能理解的项目文件。在Windows上这个构建系统通常是Visual Studio的MSBuild或者Ninja。cmake-3.24.4-windows-x86_64.zip这个包是“纯净”的CMake它不包含任何编译器。它需要知道你系统里装了什么编译器才能为其生成项目文件。这就是“生成器”的作用。当你运行cmake .时CMake会自动检测系统环境选择一个它认为合适的生成器。但自动检测常常出问题尤其是当你安装了多个版本的Visual Studio时。所以显式指定生成器是最佳实践。如何查看和指定生成器在命令行中进入你的项目源码目录假设该目录下已有CMakeLists.txt先创建一个用于构建的目录这叫做“Out-of-Source Build”是好习惯能保持源码目录清洁mkdir build cd build然后使用-G参数指定生成器。要查看当前CMake支持哪些生成器可以运行cmake -G对于Visual Studio 2019你应该看到类似“Visual Studio 16 2019”的选项。那么完整的配置命令就是cmake .. -G Visual Studio 16 2019 -A x64这里..表示CMakeLists.txt在上一级目录。-G Visual Studio 16 2019明确告诉CMake“请为VS2019生成解决方案”。-A x64指定目标平台为64位x86_64。这是关键如果你省略了-A默认可能会生成Win3232位的项目这与你x86_64的CMake和64位系统可能不匹配导致后续编译出现各种奇怪问题。3.2 解决“Generator不匹配”错误现在我们来解剖那个经典错误cmake error: error: generator : visual studio 16 2019 does not match the generator used previously。这个错误通常发生在你多次运行cmake命令但使用了不同的生成器或参数。CMake会在构建目录本例中的build下生成一个CMakeCache.txt文件它缓存了第一次配置时的所有参数包括生成器。错误场景复现第一次你在build目录下执行了cmake ..没有指定-G和-ACMake可能自动选择了“Visual Studio 16 2019”但平台是Win32并写入了缓存。第二次你想生成64位项目执行了cmake .. -G “Visual Studio 16 2019” -A x64。CMake检查缓存发现生成器信息虽然名字一样但缓存里可能隐含了平台信息不一致于是报错。根治方案 最彻底的办法是清空构建目录重新开始。因为CMakeCache.txt是问题的根源。# 在项目根目录下 rmdir /s /q build # 删除旧的build目录 mkdir build cd build cmake .. -G “Visual Studio 16 2019” -A x64 # 使用完整、正确的参数重新配置养成“为每个不同的配置创建独立的构建目录”的习惯比如build_vs2019_x64build_ninja_debug可以从根本上避免这类缓存冲突。3.3 生成后的操作编译与安装配置成功后你的build目录下会生成一个YourProject.sln文件。你可以用两种方式编译命令行编译推荐便于自动化# 仍在build目录下 cmake --build . --config Release这个命令是跨平台的它调用了底层生成器这里是MSBuild来执行编译。--config Release指定构建“Release”配置。你也可以换成Debug。IDE打开直接用Visual Studio 2019打开YourProject.sln文件像普通项目一样进行编译和调试。如果需要安装将编译好的头文件、库文件复制到指定目录如CMAKE_INSTALL_PREFIX可以在命令行使用cmake --build . --config Release --target install或者在Visual Studio中生成INSTALL项目。4. 避坑指南Windows下的路径、编码与工具链陷阱在Windows上用CMake除了生成器还有几个“特色”坑点需要特别注意。4.1 路径中的空格与中文CMake源于Unix世界对路径中的空格比较敏感。虽然现代CMake处理得已经好很多但依然建议将CMake安装在无空格、无中文的路径下。这就是为什么我推荐D:\DevTools而不是C:\Program Files。Program Files中间的空格在某些极端情况下比如在命令行参数中传递路径时如果引号处理不当可能引发问题。项目源码路径也遵循此原则。避免把项目放在桌面或我的文档这类可能包含中文或空格的目录下。使用纯英文、无空格的路径如D:\Projects\my_cmake_project能省去很多不必要的麻烦。4.2 文件编码与脚本执行“windows乱码的乱码大全”这个热搜词背后是Windows默认编码GBK与开源世界主流编码UTF-8的冲突。这会影响CMakeLists.txt中的注释、字符串以及CMake执行过程中输出的信息。解决方案编辑器设置确保你的代码编辑器如VSCode、Notepad、Sublime Text将CMakeLists.txt以及所有.cpp、.h文件以UTF-8 without BOM的编码格式保存。在VSCode中右下角可以点击切换编码。PowerShell/CMD编码在中文Windows上CMD默认是GBKPowerShell的默认编码可能随版本变化。如果你在脚本中输出或处理中文可能会乱码。对于CMake构建本身只要源文件是UTF-8通常问题不大。但如果需要在构建前后执行自定义脚本需要注意编码转换。一个治本的方法是使用Windows Terminal并将其默认配置文件中的编码设置为UTF-8。4.3 与其他工具链的协作Cygwin、MinGW、WSL从热搜词cygwin cmake和适用于 linux 的 windows 子系统可以看出很多开发者是在混合环境下工作。Cygwin/MinGW这些是Windows上的POSIX兼容层或GNU工具链。如果你需要为它们构建项目在运行CMake时需要指定对应的生成器例如-G “MinGW Makefiles”。并且你需要确保gcc、g、make等工具已在PATH中且顺序正确在MSVC工具链之前。通常更推荐使用独立的mingw64发行版并将其bin目录加入PATH前端。WSLWindows Subsystem for Linux这是更彻底的方案。你可以在WSL的Ubuntu中直接使用apt-get install cmake安装的CMake然后在Linux环境下进行纯正的GNU/Linux构建。此时cmake-3.24.4-windows-x86_64.zip这个Windows原生版本就用不上了。两者是完全独立的环境。如果你在Windows文件资源管理器中操作WSL下的文件需要注意文件系统权限和行尾符CRLF vs LF可能带来的问题。4.4 依赖管理find_package的挑战在Linux上库文件通常安装在标准路径如/usr/libfind_package很容易找到。在Windows上第三方库可能散落在任何地方。你需要通过设置CMAKE_PREFIX_PATH变量来告诉CMake去哪里找。例如如果你将OpenCV安装在D:\DevTools\opencv那么在CMake配置时可以这样做cmake .. -G “Visual Studio 16 2019” -A x64 -DCMAKE_PREFIX_PATHD:\DevTools\opencv\build或者在CMakeLists.txt中在find_package(OpenCV REQUIRED)之前使用set(CMAKE_PREFIX_PATH “D:/DevTools/opencv/build”)。对于没有提供CMake配置文件的库你可能需要手动指定XXX_INCLUDE_DIR和XXX_LIBRARY变量这是一个更繁琐但Windows C开发中无法回避的过程。本文还有配套的精品资源点击获取