Qt 从 qmake 转向 CMake 是其构建系统战略的重大转型，这一转变在 Qt6 中全面落地。下面从 技术、生态、工程实践 三个维度，系统解释：
一、Qt 使用 CMake 的核心好处
1. 强大的跨平台与多编译器支持
- CMake 原生支持：
- Windows（MSVC、MinGW）
- Linux（GCC、Clang）
- macOS（Clang/Xcode）
- Android、iOS、嵌入式（QNX、INTEGRITY）
- 自动适配不同平台的构建工具链（Ninja、MSBuild、Xcode 等）
💡 qmake 对非 Qt 项目的平台支持弱，且难以扩展。
2. 无缝集成第三方库
- 通过
find_package()、FetchContent、VCPKG、Conan等方式轻松引入外部依赖。 - 示例：集成 OpenCV、SQLite、Protobuf 等只需几行代码：
-
find_package(OpenCV REQUIRED) -
target_link_libraries(myapp PRIVATE ${OpenCV_LIBS})
-
❌ qmake 需手动写
.pri文件或硬编码路径，维护成本高。
3. 现代 C++ 工程标准
- CMake 是 C++ 社区事实标准（被 Google、Microsoft、NVIDIA 等广泛采用）
- 支持：
- C++ 标准版本控制（
CXX_STANDARD 17/20） - 编译选项精细控制（警告、优化、宏定义）
- 并行构建（Ninja 后端速度极快）
- C++ 标准版本控制（
4. 完整的开发生命周期支持
| 功能 | CMake 支持 | qmake 支持 |
|---|---|---|
| 单元测试（CTest） | ✅ 原生集成 | ❌ 需手动脚本 |
| 安装与打包（install） | ✅ install() 命令 | ⚠️ 有限支持 |
| 生成 IDE 项目文件 | ✅ VS/Xcode/CLion 等 | ⚠️ 仅部分支持 |
| 静态分析/CI/CD | ✅ 天然契合 | ❌ 困难 |
5. 更好的模块化与可维护性
- CMake 支持
add_subdirectory()实现多模块项目 - 可编写可复用的 CMake 模块（
.cmake文件） - 逻辑清晰，易于团队协作
📌 qmake 的
.pro文件在大型项目中容易变得混乱（“面条式配置”）
二、Qt 为什么放弃 qmake？
1. qmake 的设计局限性
- 语法简单但功能弱：缺乏条件逻辑、函数、作用域等编程能力
- 扩展性差：无法轻松支持新平台或新工具链
- 非标准：只有 Qt 项目使用，社区生态孤立
📝 官方评价（Qt 公司博客）：
“qmake has served us well, but it’s reached its limits in terms of scalability and maintainability.”
2. Qt 自研构建系统 qbs 的失败
- Qt 曾尝试推出 qbs（基于 JavaScript 的构建系统）
- 但因：
- 学习曲线陡峭
- 社区接受度低
- 维护成本高
- 最终于 2019 年宣布停止开发
⏪ 这迫使 Qt 必须选择一个已有强大生态的构建系统 → CMake 成为唯一合理选择。
3. 行业趋势倒逼
- 主流 C++ 项目（如 LLVM、VTK、OpenCV）全部使用 CMake
- 开发者期望“一套构建系统走天下”
- Visual Studio、CLion、VS Code 等 IDE 对 CMake 原生支持远超 qmake
📊 数据：GitHub 上 CMake 项目数量是 qmake 的 100 倍以上
4. Qt 自身架构演进需求
- Qt6 强调 模块化、轻量化、云原生
- 需要更灵活的构建系统来：
- 按需编译子模块
- 支持 WebAssembly、Android AAR 等新目标
- 与 Conan/VCPKG 等现代包管理器集成
❌ qmake 无法满足这些现代工程需求。
三、qmake vs CMake 关键对比
| 特性 | qmake | CMake |
|---|---|---|
| 语言 | 自定义 .pro 语法 | CMake 脚本语言（类 DSL） |
| 跨平台 | 有限（主要为 Qt 服务） | 极强（全平台） |
| 第三方库集成 | 困难 | 简单（find_package） |
| 社区生态 | Qt 专属 | 全 C++ 社区 |
| IDE 支持 | Qt Creator 为主 | VS / Xcode / CLion / Qt Creator 全支持 |
| 未来前景 | ❌ 已弃用（Qt6 不推荐） | ✅ Qt 官方主推 |
📌 Qt 官方明确表示：qmake 在 Qt6 中仅用于维护旧项目，新项目必须用 CMake。
四、对开发者的建议
- 新项目：直接使用 CMake + Qt6
- 旧项目迁移：
- 小项目：手动重写
CMakeLists.txt - 大项目：使用工具辅助（如
qmake2cmake脚本，但需人工校验）
- 小项目：手动重写
- 学习重点：
- 掌握
find_package(Qt6 ...) - 理解
AUTOMOC/AUTOUIC/AUTORCC - 学会使用
qt_add_executable()（Qt6.3+ 新封装）
- 掌握
✅ 总结
Qt 转向 CMake 不是“折腾”，而是“进化”。
- 对 Qt 公司：降低维护成本，拥抱开源生态
- 对开发者：获得更强大、更标准、更未来的构建体验
虽然 CMake 初学曲线略陡，但它是 现代 C++ 开发的必备技能，投资回报极高。
五、qmake 是什么？
- qmake 是 Qt 自 2002 年起随 Qt 3 引入的专用构建系统。
- 核心功能：读取
.pro文件，生成 Makefile（Linux/macOS）或 Visual Studio 项目（Windows）。 - 优点：
- 简单易用（几行代码就能编译 Qt 项目）
- 自动处理 MOC/UIC/RCC
- 与 Qt Creator 深度集成
- 缺点：
- 语法简陋，缺乏编程能力（无函数、作用域、复杂逻辑）
- 扩展性差（难以支持新平台或非 Qt 依赖）
- 仅适用于 Qt 项目，生态封闭
📌 qmake 本质是一个“为 Qt 量身定制的轻量级构建生成器”。
六、为什么 Qt 要推出 qbs？（动机）
大约在 2011–2013 年，Qt 团队意识到 qmake 已无法满足现代 C++ 项目的复杂需求，于是启动了 qbs 项目。
✅ qbs 的设计目标：
| 目标 | 说明 |
|---|---|
| 统一构建流程 | 不再生成中间文件（如 Makefile），而是直接调用编译器，实现“声明式构建” |
| 高性能 | 基于增量构建和智能缓存，比 qmake + make 更快 |
| 跨平台原生支持 | 内置对 MSVC、GCC、Clang、Xcode 等的支持，无需生成中间项目文件 |
| 现代语言特性 | 使用类似 JavaScript 的脚本语言（基于 QtScript），支持函数、模块、条件逻辑 |
| 脱离 Make 依赖 | 在 Windows 上不再依赖 MinGW/MSYS，纯原生构建 |
💡 qbs 的口号是：“Build once, run anywhere — without Makefiles.”
七、qbs 和 qmake 的关系
| 维度 | qmake | qbs |
|---|---|---|
| 定位 | 轻量级项目生成器 | 完整的构建执行引擎 |
| 工作方式 | 生成 Makefile / .vcxproj → 调用 make/msbuild | 直接解析项目文件 → 调用编译器（无中间文件） |
| 配置语言 | 自定义 .pro 语法（简单但弱） | JavaScript-like 脚本（.qbs 文件，更强大） |
| 依赖管理 | 手动指定路径 | 支持模块化依赖和自动查找 |
| 与 Qt 集成 | 深度绑定 | 同样深度绑定，但更灵活 |
🔄 qbs 不是 qmake 的升级版，而是一个全新设计的替代品。
八、qbs 为何失败？
尽管技术先进，qbs 最终在 2019 年被 Qt 官方宣布停止开发。原因如下：
1. 社区接受度极低
- 开发者已习惯 CMake/qmake
- 学习新语法成本高（“又一个 DSL”）
- 缺乏第三方库支持（没人写
.qbs配置）
2. CMake 的崛起
- CMake 在 2010 年代后期迅速成为 C++ 构建事实标准
- Google、Microsoft、NVIDIA 等大厂全面采用
- CMake 3.0+ 引入
target_*命令后，现代 CMake 语法清晰且强大
3. 维护成本过高
- Qt 团队需同时维护 qmake、qbs、CMake 支持
- 资源有限，不如聚焦一个主流方案
4. IDE 支持不足
- 除 Qt Creator 外，其他 IDE（VS、CLion）对 qbs 几乎无支持
- 而 CMake 被所有主流 IDE 原生支持
📝 Qt 官方博客（2018）坦言：
“While qbs has some technical advantages, the ecosystem has clearly chosen CMake.”
九、Qt 的最终选择：拥抱 CMake
- 2016 年：Qt 5.7 开始实验性支持 CMake
- 2018 年：Qt 5.12 提供完整 CMake 支持
- 2020 年：Qt 6.0 默认使用 CMake，qmake 降级为兼容模式
- 2019 年：正式宣布 停止 qbs 开发
✅ 这标志着 Qt 彻底放弃“自研构建系统”，转而融入 C++ 主流生态。
三者关系总结
-
qmake (2002) -
└── 简单但局限 → 无法满足现代需求 -
↓ -
qbs (2013) -
└── 技术先进但生态失败 → 被社区抛弃 -
↓ -
CMake (2020+) -
└── 行业标准 → Qt 全面拥抱
对开发者的启示
- 不要重复造轮子：即使技术更优，若脱离生态，难逃失败
- 顺应行业趋势：CMake 已成为 C++ 构建的“普通话”
- Qt 的务实转型：从“自给自足”转向“融入生态”，是成熟开源项目的标志
✅ 总结
| 问题 | 答案 |
|---|---|
| qbs 是什么？ | Qt 推出的新一代构建系统，试图替代 qmake |
| qbs 和 qmake 关系？ | qbs 是 qmake 的“精神继任者”，但架构完全不同 |
| 为什么推 qbs？ | qmake 功能不足，Qt 想要更强大、更快、更现代的构建工具 |
| 为什么放弃 qbs？ | 社区不买账，CMake 成为主流，维护成本太高 |
| 现在该用什么？ | CMake —— Qt 官方唯一推荐的新项目构建系统 |
如今，qbs 已成为 Qt 历史中的一个“技术理想主义”案例，而 CMake 则是现实的最佳选择。
扫一扫
2102
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
