【C++】CMake 构建系统选择指南：从 MinGW 到 Ninja

CMake 构建系统选择指南：从 MinGW 到 Ninja

前言

在使用 CMake 进行 C++ 项目构建时，选择合适的构建系统至关重要。本文记录了从遇到 MinGW Makefiles 中文路径问题，到切换到 Ninja 构建系统的完整过程，并对比了三种主流构建系统的特点。

问题背景

遇到的第一个问题：MinGW Makefiles 中文路径支持不佳

在使用cmake --build .构建项目时，遇到了以下错误：

mingw32-make: *** [Makefile:178: cmake_check_build_system] Error -1073740791

问题原因：

• 项目路径包含中文字符：D:\test\cmake学习\01-基础示例
• MinGW Makefiles 生成器在处理中文路径时存在编码问题
• cmake_check_build_system目标在执行时无法正确处理包含中文的路径

临时解决方案：
修改生成的Makefile，将cmake_check_build_system目标改为空操作，但这只是权宜之计。

根本解决方案：
切换到支持中文路径更好的构建系统，如 Ninja。

安装 Ninja 构建系统

为什么选择 Ninja？

1. 更好的中文路径支持：Ninja 对 Unicode 路径的支持比 MinGW Makefiles 更好
2. 构建速度快：Ninja 专注于快速构建，特别适合大型项目
3. 跨平台支持：Windows、Linux、macOS 都有良好支持

安装步骤

使用 Scoop 全局安装

1. 确保 Scoop 已安装

   # 如果未安装 Scoop，先安装Set-ExecutionPolicyRemoteSigned-Scope CurrentUserInvoke-RestMethodget.scoop.sh|Invoke-Expression

2. 全局安装 Ninja（需要管理员权限）

   # 以管理员身份运行 PowerShellscoop install-g ninja

3. 验证安装

   ninja--version

安装过程中遇到的问题

问题 1：权限不足

错误信息：

ERROR: you need admin rights to install global apps

解决方案：

• 右键点击 PowerShell，选择"以管理员身份运行"
• 然后重新执行scoop install -g ninja

问题 2：环境变量未更新

现象：

• 安装完成后，在 CMD 中可以识别ninja命令
• 但在 Cursor 的集成终端中无法识别

原因分析：

• Scoop 全局安装会将 不会把C:\ProgramData\scoop\shims添加到系统 PATH，需要手动添加
• Cursor 启动时才会读取环境变量快照
• 如果 Cursor 在 PATH 更新之前启动，终端不会自动刷新环境变量，即使在cursor内部重启启动终端也是不行的

解决方案：

重启 Cursor（推荐）
关闭并重新打开 Cursor，新的终端会读取最新的环境变量。

总结：手动添加系统 PATH，并重启Cursor

1. 按Win + R，输入sysdm.cpl，回车
2. 打开"高级"选项卡，点击"环境变量"
3. 在"系统变量"中找到Path，点击"编辑"
4. 点击"新建"，添加：C:\ProgramData\scoop\shims
5. 点击"确定"保存
6. 重启 Cursor

使用 Ninja 构建系统

配置 CMake 使用 Ninja

# 进入构建目录cd build# 使用 Ninja 生成器配置项目cmake-G"Ninja"..# 构建项目cmake--build.

验证构建

# 检查生成的文件ls# 运行可执行文件.\hello.exe

三种构建系统对比

1. MinGW Makefiles

特点：

• 使用mingw32-make作为构建工具
• 适合使用 MinGW 编译器的项目
• 生成传统的 Makefile

优点：

• 与 MinGW 工具链集成良好
• 支持并行构建（-j参数）

缺点：

• ❌中文路径支持不佳（本文遇到的主要问题）
• 构建速度相对较慢
• Windows 平台下路径处理有局限性

适用场景：

• 使用 MinGW 编译器的项目
• 路径不包含非 ASCII 字符的项目

使用示例：

cmake-G"MinGW Makefiles"..cmake--build.

2. Ninja

特点：

• 专注于快速构建的构建系统
• 生成build.ninja文件
• 支持增量构建

优点：

• ✅良好的中文路径支持
• ⚡构建速度快（比 Make 快 2-10 倍）
• 支持并行构建
• 跨平台支持好
• 构建日志清晰

缺点：

• 需要单独安装（Windows 上）
• 配置文件是二进制格式，不易手动编辑

适用场景：

• 大型项目（构建速度快）
• 路径包含中文或其他 Unicode 字符
• 需要频繁构建的项目
• 跨平台项目

使用示例：

cmake-G"Ninja"..cmake--build.# 或直接使用 ninjaninja

3. Visual Studio（默认）

特点：

• Windows 平台默认生成器
• 生成 Visual Studio 项目文件（.sln、.vcxproj）
• 可以使用 Visual Studio IDE 打开

优点：

• ✅完美支持中文路径
• 与 Visual Studio IDE 集成
• 支持多种配置（Debug、Release 等）
• 图形界面调试方便

缺点：

• 需要安装 Visual Studio（体积大）
• 构建速度不如 Ninja
• 主要面向 Windows 平台

适用场景：

• 使用 Visual Studio 开发的项目
• 需要图形界面调试
• Windows 专用项目

使用示例：

# 默认生成器（Visual Studio）cmake..# 指定 Visual Studio 版本cmake-G"Visual Studio 17 2022"..# 在 Visual Studio 中打开startHelloCMake.sln

详细对比表

实际使用建议

选择建议

1. 路径包含中文：

   • 优先选择：Ninja或Visual Studio
   • 避免使用：MinGW Makefiles

2. 跨平台项目：

   • 推荐：Ninja（所有平台都支持）

3. 使用 Visual Studio 开发：

   • 推荐：Visual Studio生成器

4. 使用 MinGW 编译器：

   • 如果路径无中文：MinGW Makefiles
   • 如果路径有中文：Ninja（配合 MinGW 编译器）

性能对比（参考）

对于同一个项目（约 100 个源文件）：

• Ninja：~5 秒（首次构建）
• MinGW Makefiles：~12 秒（首次构建）
• Visual Studio：~15 秒（首次构建）

注：实际性能取决于项目大小和硬件配置

总结

1. MinGW Makefiles 中文路径问题：

   • 这是 MinGW Makefiles 生成器的已知限制
   • 如果项目路径包含中文，建议切换到其他构建系统

2. Ninja 安装：

   • 使用 Scoop 全局安装是最简单的方法
   • 安装后需要重启 Cursor 或手动刷新环境变量

3. 构建系统选择：

   • 中文路径：优先选择 Ninja 或 Visual Studio
   • 跨平台：推荐 Ninja
   • Windows + Visual Studio：使用 Visual Studio 生成器

4. 最佳实践：

   • 开发环境：根据实际情况选择合适的构建系统
   • CI/CD：推荐使用 Ninja（构建速度快）
   • 团队协作：统一构建系统，避免环境差异

附录：常用命令

查看可用的生成器

cmake--help

清理构建目录

# Ninjaninja clean# MinGW Makefilesmingw32-make clean# Visual Studiocmake--build.--target clean

指定并行构建线程数

# Ninjacmake--build.--parallel8# MinGW Makefilescmake--build.--parallel8# Visual Studiocmake--build.--parallel8

查看构建详细输出

cmake--build.--verbose

CMake 的三条常用“-G”命令到底差在哪？

一句话速览

1. cmake -G "MinGW Makefiles" ..

   → 生成 GNU Makefile，接着用mingw32-make跑，编译器仍是 MinGW-GCC。

2. cmake -G "Ninja" ..

   → 生成 build.ninja，接着用ninja跑，编译器还是 MinGW-GCC，只是调度更快。

3. cmake -G "Visual Studio 17 2022" ..

   → 生成 .sln / .vcxproj，接着用 MSBuild 或 VS IDE 跑，编译器默认是 MSVC（cl.exe），跟 MinGW 没半点关系。

拆开细看

一、CMake 的 -G 到底是干嘛的？
只决定“我要产出哪种构建文件”。

CMake 自己不编译，把编译任务交给下游工具（make、ninja、msbuild……）。

二、三条命令的“下游”分别长啥样？

* Visual Studio可改工具链，但默认不是 MinGW。

三、速度体验

• 空项目下ninja启动毫秒级，增量构建飞快；大项目感受尤其明显。
• mingw32-make每次都要扫描文件依赖，启动慢，记得加-j。
• msbuild启动比 ninja 慢一些，但 VS 的并行度也不错；胜在图形调试方便。

四、我该选哪个？

• 习惯 VS 调试器、要做 Windows 专属特性 → Visual Studio 生成器。
• 想要最快构建速度、CI 自动化、跨平台一致 → Ninja（搭配 MinGW 或 Clang）。
• 老项目/老教程用的是 Makefile，懒得改 → MinGW Makefiles，记得手动-j。

结语
记住一句话：

“生成器决定谁来调度，工具链决定谁来编译。”

把这条想明白，再看到cmake -G xxx就不会迷糊了。

祝你构建愉快，秒编译、少踩坑！