1. 项目概述：为什么我们需要现代化的Qt构建方式

如果你是一个Qt开发者，尤其是用过QML来构建现代界面的，那你大概率经历过这样的场景：项目文件越来越多，pro文件里的配置越来越长，依赖管理一团乱麻，跨平台编译时各种路径问题层出不穷，最后只能对着Qt Creator里那个红色的错误提示叹气。我接手过不少从Qt 4时代遗留下来的项目，其构建系统之混乱，堪称“祖传屎山”，每次添加一个新模块或者升级Qt版本，都像在走钢丝。

这正是“Qt与CMake现代化构建”这个主题要解决的核心痛点。它不是一个简单的工具替换，而是一次开发范式的升级。传统的qmake（.pro文件）在Qt早期功不可没，但它本质上是一个为Qt定制的构建脚本生成器，在管理复杂项目、处理现代C++特性（如模块化、自动依赖）、以及与庞大的C++生态系统（如vcpkg, Conan包管理器）集成时，显得力不从心。而CMake，作为一个业界的、跨平台的事实标准，提供了更强大、更灵活、也更“标准”的构建描述能力。

将CMake引入Qt QML项目，意味着你可以用一套统一的语法来管理C++后端逻辑和QML前端资源，享受CMake强大的目标（Target）概念、属性继承、以及条件编译。更重要的是，它能无缝集成各种现代开发工具链，比如用CLion或VS Code获得更好的代码智能感知，用cmake-presets来一键配置不同平台（Windows/MSVC, Linux/GCC, macOS/Clang）的构建，用CPack来生成安装包。对于QML项目，CMake能更优雅地处理qrc资源文件、自动调用qmlcachegen和qmllint，甚至集成Qt Quick Compiler来提升运行时性能。

简单说，这个项目就是教你如何告别qmake的“黑盒魔法”，拥抱CMake的“声明式工程”，打造一个清晰、健壮、可维护且高效的Qt QML项目构建体系。无论你是维护一个大型客户端应用，还是开发一个嵌入式设备的UI，这套方法都能让你从构建的泥潭中解脱出来，把精力真正放在业务逻辑和创新上。

2. 核心思路与方案选型：CMake vs QMake的深度权衡

决定用CMake重构Qt项目，不是一个拍脑袋的决定。我们需要深入理解两种工具的哲学差异和适用场景，才能做出最合适的选择。

2.1 QMake的功与过：为什么它开始显得“过时”

QMake是Qt的亲儿子，它的设计初衷就是让Qt应用的构建变得简单。你写一个.pro文件，指定QT += core gui qml quick，它就能帮你找到正确的头文件路径、链接库，并生成Makefile或Visual Studio项目。对于小型到中型的纯Qt项目，它非常直观高效。

然而，随着项目复杂度提升，QMake的局限性日益凸显：

1. 语法晦涩且非标准：.pro文件的语法是Qt自创的，像SOURCES +=,HEADERS +=这种基于变量的指令，在管理大量文件时容易混乱。条件判断（win32:,unix:）和函数（$$system()）的写法也独树一帜，学习成本和维护成本都在增加。
2. 依赖管理能力弱：对于项目内部的子模块（比如一个独立的网络库或工具库），QMake虽然支持SUBDIRS，但模块间的依赖关系、导出接口管理起来很麻烦。对于外部第三方库（非Qt），通常需要手动写LIBS += -L/path/to -llibname和INCLUDEPATH += /include/path，跨平台时需要写多套条件分支，极易出错。
3. 与生态脱节：现代C++项目大量使用find_package来查找依赖，而QMake无法原生支持。如果你想用vcpkg或Conan安装的库，得费很大劲把路径“喂”给QMake。像单元测试框架（Google Test, Catch2）、代码覆盖率（gcov）、静态分析（clang-tidy）等工具链，与CMake的集成远比对QMake友好。
4. 构建生成物控制不精细：QMake对生成的目标（Target）属性控制相对粗糙。而CMake可以针对每个目标（可执行文件、静态库、动态库）精确设置编译选项、链接选项、预处理器定义等。

2.2 CMake的现代化优势：不仅仅是“替代”

CMake采用声明式的CMakeLists.txt文件，它描述的是“要构建什么”（目标及其属性），而不是“如何构建”（具体的编译命令）。这种抽象层次更高，也更具可移植性。

对于Qt QML项目，CMake的核心优势体现在：

1. 一流的Qt集成：从CMake 3.16开始，官方提供了卓越的Qt支持模块。通过find_package(Qt6 COMPONENTS Core Quick REQUIRED)，你可以以完全面向目标的方式使用Qt。关联一个目标（如你的应用程序）和Qt模块变得极其简单：target_link_libraries(myapp Qt::Core Qt::Quick)。CMake会自动处理所有包含路径、编译定义和链接库，甚至是平台特定的细节。
2. 卓越的QML资源处理：CMake可以自动处理.qrc文件。当你将QRC文件添加到目标时，CMake会确保在构建过程中调用rcc工具将其编译成C++代码并链接进去。更重要的是，它可以集成qt_add_qml_module（Qt 6）或qt6_add_qml_module，这是一个革命性的功能。它能自动扫描你的QML文件，生成必要的元信息，调用qmlcachegen进行预编译，极大优化QML的加载和执行性能，这是用QMake手动配置难以比拟的。
3. 结构化与模块化：CMake鼓励你将项目拆分为多个子目录，每个子目录一个CMakeLists.txt，通过add_subdirectory()引入。库和应用程序之间的依赖可以通过target_link_libraries()清晰表达。你可以轻松地创建项目内的共享库，并控制其接口（使用PUBLIC、PRIVATE、INTERFACE关键字传播属性）。
4. 跨平台与工具链统一：一份CMakeLists.txt，配合cmake-presets.json，可以在Windows（MSVC/Ninja）、Linux（GCC/Clang）、macOS（Xcode）上无缝构建，无需修改构建脚本。它也能完美适配CLion、VS Code、Qt Creator（新版）等IDE，提供一致的项目体验。

注意：迁移到CMake并非没有代价。对于历史悠久的巨型QMake项目，迁移可能是一项浩大的工程。你需要评估收益和成本。对于新项目，我强烈建议直接从CMake开始。

2.3 方案选型结论：何时该用CMake？

基于以上分析，我建议在以下场景坚定选择CMake：

• 全新的Qt项目，尤其是使用Qt 6的。
• 中大型项目，涉及多个内部模块或大量第三方依赖。
• 需要深度集成现代C++开发工具链（如CI/CD、静态分析、包管理）的项目。
• 团队熟悉CMake或希望技能与更广泛的C++社区接轨。
• 追求极致构建性能和可维护性的项目。

而对于小型、一次性或纯演示性的Qt项目，Qmake的快速上手优势依然存在。但长远看，CMake的技能树投资回报率更高。

3. 从零搭建一个现代化Qt QML项目的CMake框架

理论说再多，不如动手搭一个。下面我将一步步展示如何为一个典型的Qt Quick应用搭建一个清晰、健壮的CMake项目结构。我们假设项目名为ModernQtApp。

3.1 项目目录结构设计

一个良好的结构是成功的一半。我推荐以下结构，它分离了源代码、资源、构建产出和配置：

ModernQtApp/ ├── CMakePresets.json # CMake预设，用于一键配置不同环境 ├── CMakeLists.txt # 项目根CMake文件 ├── cmake/ # 自定义CMake模块（可选） │ └── FindSomeLib.cmake ├── src/ # 主应用程序源代码 │ ├── CMakeLists.txt │ ├── main.cpp │ ├── backend/ # C++ 后台逻辑 │ │ ├── CMakeLists.txt │ │ ├── Engine.{h,cpp} │ │ └── ... │ └── resources/ # 应用程序资源（如图标） │ └── appicon.ico ├── qml/ # QML前端代码和资源 │ ├── CMakeLists.txt │ ├── main.qml │ ├── components/ # 可复用QML组件 │ │ └── CustomButton.qml │ ├── pages/ # 页面 │ │ └── HomePage.qml │ └── assets/ # QML使用的图片、字体等 │ └── logo.png ├── libs/ # 项目内部的库（如果有） │ └── myutils/ │ ├── CMakeLists.txt │ └── ... ├── tests/ # 单元测试 │ ├── CMakeLists.txt │ └── test_engine.cpp └── build/ # 构建输出目录（通常被.gitignore）

这个结构的关键在于分离关注点：src管C++，qml管界面，libs管内部共享代码。每个主要目录都有自己的CMakeLists.txt，由根目录的CMake文件统领。

3.2 根目录CMakeLists.txt详解

这是项目的总入口，负责设置全局策略、寻找Qt、并包含子目录。

# ModernQtApp/CMakeLists.txt cmake_minimum_required(VERSION 3.21) # 建议至少3.21，对Qt6支持好 project(ModernQtApp VERSION 1.0.0 LANGUAGES CXX) # 1. 设置全局CMake策略。这能避免很多兼容性警告，并启用一些推荐行为。 # 例如，CMP0071和CMP0074让`find_package`对Qt更友好。 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) # 禁用编译器扩展（如GNU的），保证标准C++ if (POLICY CMP0071) cmake_policy(SET CMP0071 NEW) # 让`find_package`优先使用`<PackageName>_ROOT` endif() if (POLICY CMP0074) cmake_policy(SET CMP0074 NEW) # 让`find_package`使用`<PackageName>_ROOT`查找Qt endif() # 2. 自动包含当前构建目录和二进制目录到头文件搜索路径。 # 这有助于找到构建时生成的头文件（如由`qt_add_qml_module`生成的文件）。 list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake") # 3. 查找Qt6。使用`REQUIRED`确保找不到时直接报错。 # `COMPONENTS`指定我们需要的模块。Core和Quick是基础，你还可以加Gui, Network等。 find_package(Qt6 6.5 REQUIRED COMPONENTS Core Quick) # 4. 启用Qt的自动代码生成功能（如MOC, UIC, RCC）。 # 这是必须的，否则Qt的信号槽、元对象系统都无法工作。 set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOUIC ON) set(CMAKE_AUTORCC ON) # 5. 添加子目录。顺序很重要，先添加库（依赖项），再添加依赖它们的目标。 add_subdirectory(libs/myutils) # 如果有内部库 add_subdirectory(src) # 主应用程序 add_subdirectory(qml) # QML模块 add_subdirectory(tests) # 测试（可选） # 6. 安装规则（可选，用于打包）。这里简单地将可执行文件安装到bin目录。 install(TARGETS ModernQtApp RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR} )

这个文件设置了项目的基石。find_package是核心，它告诉CMake去查找你系统上安装的Qt。CMAKE_AUTOMOC等开关是Qt与CMake协同工作的魔法开关，必须打开。

3.3 核心模块CMakeLists.txt解析

接下来，我们深入最重要的两个部分：src/和qml/。

3.3.1 src/CMakeLists.txt - 定义C++应用程序

# src/CMakeLists.txt # 1. 创建一个可执行文件目标，名字就是项目名。 add_executable(ModernQtApp) # 2. 指定这个目标的源代码文件。这里使用相对路径。 target_sources(ModernQtApp PRIVATE main.cpp backend/Engine.cpp ) # 对应的头文件通常不需要显式列出，因为`AUTOMOC`会扫描。 # 但如果你有纯头文件的类（如模板类），可能需要手动添加。 # 3. 指定头文件的包含目录。 # `PUBLIC`意味着任何链接`ModernQtApp`的目标也能看到这些头文件。 target_include_directories(ModernQtApp PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} # 包含src目录本身 ${CMAKE_CURRENT_SOURCE_DIR}/backend # 包含backend子目录 ) # 4. 链接所需的Qt模块和其他库。 # 注意这里用的是`Qt::Core`和`Qt::Quick`，这是`find_package(Qt6)`提供的导入目标。 # 这种用法是面向目标的，CMake会自动处理所有细节。 target_link_libraries(ModernQtApp PRIVATE Qt::Core Qt::Quick # 如果链接了内部库，例如： # myutils ) # 5. 设置目标属性：例如在Windows下设置子系统为WINDOWS（不显示控制台窗口）。 set_target_properties(ModernQtApp PROPERTIES WIN32_EXECUTABLE ON MACOSX_BUNDLE ON # 在macOS上生成.app包 ) # 6. 添加资源文件（如图标、翻译文件.qm）。 # 假设我们有一个app.qrc文件在resources目录下 qt_add_resources(ModernQtApp "app_resources" PREFIX "/" FILES resources/app.qrc )

3.3.2 qml/CMakeLists.txt - 定义QML模块（Qt 6推荐方式）

这是现代化构建的精髓。在Qt 6中，强烈推荐使用qt_add_qml_module来管理QML。

# qml/CMakeLists.txt # 1. 定义一个QML模块。这会创建一个库目标（默认是静态库），并处理所有QML相关的构建步骤。 qt_add_qml_module(ModernQtApp.QML # 模块的URI。在QML中导入时使用 `import ModernQtApp.QML 1.0` URI ModernQtApp.QML VERSION 1.0 # 指定QML文件。CMake会自动扫描这些文件的依赖。 QML_FILES main.qml components/CustomButton.qml pages/HomePage.qml # 指定资源文件（如图片）。它们会被自动打包进模块。 RESOURCES assets/logo.png # 如果QML文件需要调用C++类，在这里指定对应的C++源文件和头文件。 # 这会自动生成必要的胶水代码（plugin.cpp）。 # SOURCES # somebackend.cpp # somebackend.h ) # 2. 将QML模块链接到主应用程序。 # 这样，应用程序就能找到并加载这个QML模块了。 target_link_libraries(ModernQtApp PRIVATE ModernQtApp.QML)

qt_add_qml_module做了大量幕后工作：它运行qmlcachegen来预编译QML文件为字节码（提升启动速度），运行qmllint进行语法检查（如果配置了），并生成一个qmldir文件。生成的ModernQtApp.QML目标是一个库，主程序链接它后，QML引擎就能通过URI定位到我们的QML文件。

3.4 使用CMake Presets简化构建流程

手动在命令行输入cmake -B build -S . -DCMAKE_PREFIX_PATH=/path/to/qt很麻烦，尤其是路径很长时。CMake Presets（3.19+）可以让你把配置保存为JSON文件。

// CMakePresets.json { "version": 3, "configurePresets": [ { "name": "windows-msvc", "displayName": "Windows MSVC 2022", "description": "使用Visual Studio 2022和Qt 6.5构建", "generator": "Visual Studio 17 2022", "architecture": "x64", "cacheVariables": { "CMAKE_PREFIX_PATH": "C:/Qt/6.5.0/msvc2019_64", // 你的Qt安装路径 "CMAKE_INSTALL_PREFIX": "${sourceDir}/out/install/${presetName}" }, "environment": {} }, { "name": "linux-gcc", "displayName": "Linux GCC", "description": "在Linux上使用GCC和Qt 6.5构建", "generator": "Unix Makefiles", "cacheVariables": { "CMAKE_PREFIX_PATH": "/home/user/Qt/6.5.0/gcc_64", "CMAKE_BUILD_TYPE": "RelWithDebInfo" } }, { "name": "macos-xcode", "displayName": "macOS Xcode", "description": "在macOS上使用Xcode和Qt 6.5构建", "generator": "Xcode", "cacheVariables": { "CMAKE_PREFIX_PATH": "/Users/user/Qt/6.5.0/clang_64", "CMAKE_OSX_ARCHITECTURES": "arm64;x86_64" } } ], "buildPresets": [ { "name": "windows-debug", "configurePreset": "windows-msvc", "configuration": "Debug" } ] }

配置好后，在项目根目录，你只需要：

# 配置 cmake --preset=linux-gcc # 构建 cmake --build --preset=windows-debug

这极大地简化了跨平台和团队协作的构建流程。VS Code、CLion等IDE也能自动识别并使用这些预设。

4. 高级技巧与深度优化配置

基础框架搭好了，但要打造一个工业级的构建系统，还需要一些“高级货”。

4.1 处理第三方依赖：以vcpkg为例

如果你的项目需要用到spdlog做日志，nlohmann/json处理JSON，用vcpkg管理是最佳实践。CMake可以无缝集成。

首先，在CMakeLists.txt顶部或通过CMakePresets.json的cacheVariables设置CMAKE_TOOLCHAIN_FILE：

# 在CMakeLists.txt中（不推荐硬编码，最好用preset） # set(CMAKE_TOOLCHAIN_FILE "C:/dev/vcpkg/scripts/buildsystems/vcpkg.cmake" CACHE STRING "")

然后，直接使用find_package：

find_package(spdlog CONFIG REQUIRED) find_package(nlohmann_json CONFIG REQUIRED) target_link_libraries(ModernQtApp PRIVATE spdlog::spdlog nlohmann_json::nlohmann_json )

CMake会通过vcpkg提供的脚本来定位这些库。这比手动管理include_directories和link_directories干净一万倍。

4.2 为QML启用严格模式与编译缓存

为了获得更好的QML运行时性能和早期错误检测，可以配置Qt的构建特性。

# 在调用`qt_add_qml_module`之前，可以设置一些目标编译特性。 # 但更常见的做法是在主目标上设置，因为它们会传递。 target_compile_definitions(ModernQtApp PRIVATE # 启用QML的严格模式，在开发阶段捕获更多类型错误。 QT_QML_DEBUG # 如果你购买了Qt Quick Compiler许可证，可以定义以下宏来启用AOT编译。 # QT_QUICK_COMPILER ) # 另一种方式是通过设置Qt自身的特性。 # 你可以尝试在find_package后设置，但并非所有特性都可通过此方式控制。

对于QML缓存，qt_add_qml_module默认会根据Qt的配置来处理。你可以通过设置CMake变量QT_QUICK_CACHE来影响它，但通常默认值就是最优的。

4.3 分平台配置与条件编译

虽然CMake尽力抽象平台差异，但有时仍需处理平台特定代码或资源。

# 平台判断 if(WIN32) target_sources(ModernQtApp PRIVATE platform/WindowsHelper.cpp ) # Windows下设置应用程序图标 set(RESOURCE_FILES ${RESOURCE_FILES} resources/appicon.rc) elseif(APPLE) target_sources(ModernQtApp PRIVATE platform/macOSHelper.mm # Objective-C++文件 ) # 设置macOS Bundle属性 set_target_properties(ModernQtApp PROPERTIES MACOSX_BUNDLE_BUNDLE_NAME "ModernQtApp" MACOSX_BUNDLE_ICON_FILE "appicon.icns" ) elseif(UNIX AND NOT APPLE) # Linux # 安装桌面入口文件 install(FILES linux/ModernQtApp.desktop DESTINATION ${CMAKE_INSTALL_DATAROOT}/applications) endif() # 处理.rc资源文件（Windows） if(RESOURCE_FILES) set(CMAKE_RC_COMPILER_INIT windres) enable_language(RC) target_sources(ModernQtApp PRIVATE ${RESOURCE_FILES}) endif()

4.4 集成单元测试

使用CMake的CTest模块可以轻松集成测试。

# tests/CMakeLists.txt if(BUILD_TESTING) # 通常由主CMakeLists.txt的`enable_testing()`或预设控制 find_package(Qt6 REQUIRED COMPONENTS Test) find_package(GTest CONFIG REQUIRED) # 假设使用Google Test add_executable(ModernQtAppTests test_engine.cpp # 其他测试文件 ) target_link_libraries(ModernQtAppTests PRIVATE ModernQtApp # 链接被测试的主程序（或具体库） Qt::Test GTest::gtest GTest::gtest_main ) # 将测试目标添加到CTest add_test(NAME EngineTests COMMAND ModernQtAppTests) endif()

然后在命令行运行ctest或从IDE中运行测试即可。

5. 实战避坑指南与常见问题排查

迁移或新建项目过程中，你会遇到不少坑。这里记录了我踩过的一些，以及解决方法。

5.1 常见CMake配置错误

问题1：CMake找不到Qt (Could NOT find Qt6)

• 原因：最常见的原因是CMAKE_PREFIX_PATH没有设置或设置错误。CMake不知道去哪里找Qt。
• 解决：
  1. 确保Qt已安装且路径正确。
  2. 通过命令行参数传递：cmake -B build -S . -DCMAKE_PREFIX_PATH="C:/Qt/6.5.0/msvc2019_64"。
  3. 最佳实践：使用CMakePresets.json，将路径写入预设的cacheVariables中，一劳永逸。
  4. 检查Qt安装目录下是否有lib/cmake子目录，CMake是通过这个目录下的Qt6Config.cmake来定位的。

问题2：MOC/UIC/RCC未运行，导致编译错误（如“Q_OBJECT class has no vtable”）

• 原因：CMAKE_AUTOMOC,AUTOUIC,AUTORCC没有设置为ON，或者相关源文件没有被target_sources正确包含。
• 解决：
  1. 确保在find_package(Qt6)之后，立即设置这三个变量为ON。
  2. 确保包含Q_OBJECT宏的头文件被添加到目标的源文件列表中（或在其PUBLIC/PRIVATE头文件目录中能被扫描到）。对于qt_add_qml_module，它会自动处理关联的C++文件。
  3. 清理构建目录并重新生成，有时CMake的依赖扫描需要重新触发。

问题3：链接错误，找不到Qt的符号（如undefined reference tovtable for QObject`）

• 原因：链接顺序错误，或者没有链接到必要的Qt模块。
• 解决：
  1. 使用target_link_libraries的现代CMake语法，链接Qt::Core,Qt::Quick等导入目标。不要使用旧的${Qt6Core_LIBRARIES}变量。
  2. 确保所有使用Qt特性的目标（库或可执行文件）都链接了相应的Qt模块。例如，一个纯工具库如果用了QString，也需要链接Qt::Core。
  3. 检查find_package时是否包含了所有必需的COMPONENTS。

5.2 QML模块相关陷阱

问题4：运行时QML文件找不到（“module ‘ModernQtApp.QML’ is not installed”）

• 原因：qt_add_qml_module生成的模块资源没有被正确部署或主程序没有链接该模块。
• 解决：
  1. 确认主程序的target_link_libraries中包含了你的QML模块目标（如ModernQtApp.QML）。
  2. 在开发时，确保构建系统将编译后的QML模块（通常是.qml文件的缓存和资源）放在可执行文件能找到的位置。qt_add_qml_module默认会处理好这些。
  3. 如果问题出现在部署后（比如复制到其他机器），你需要确保将生成的QML模块文件（在构建目录下的相关子文件夹，如qml/ModernQtApp/QML/）随可执行文件一起打包。Qt的部署工具（windeployqt,macdeployqt,linuxdeployqt）在识别到CMake目标后，通常能自动处理这部分。

问题5：QML类型注册失败

• 原因：在QML中使用的C++类型，没有通过qmlRegisterType正确注册，或者在CMake中关联QML模块时，对应的C++源文件没有在qt_add_qml_module的SOURCES参数中列出。
• 解决：
  1. 在C++文件中使用qmlRegisterType注册你的类。
  2. 在qt_add_qml_module调用中，确保将定义这些类的.cpp和.h文件列在SOURCES参数里。这样CMake才会为这个QML模块生成正确的插件初始化代码。

5.3 构建性能与缓存优化

问题6：每次构建都重新运行MOC，即使头文件没改

• 原因：CMake的自动扫描依赖可能在某些情况下不完善。
• 解决：这通常是CMake/Ninja版本或Qt版本的问题。可以尝试：
  1. 升级到最新稳定版的CMake和Qt。
  2. 使用Ninja作为生成器（-G Ninja），它的依赖跟踪通常比Makefiles更精确。
  3. 对于特别复杂的项目，可以考虑将频繁变动且不涉及Q_OBJECT的声明移到一个单独的、不包含Q_OBJECT的头文件中，减少MOC的触发范围。

问题7：构建目录巨大

• 原因：CMake的生成文件、中间文件、以及Qt生成的大量MOC/UIC/RCC文件都放在构建目录。
• 解决：
  1. 这是正常现象。使用.gitignore忽略整个build/或out/目录。
  2. 考虑使用ccache来加速重复编译。在Linux/macOS上安装ccache，并在CMake配置时加上-DCMAKE_CXX_COMPILER_LAUNCHER=ccache。Windows上也有类似工具如sccache。
  3. 对于Debug构建，可以关闭QT_QML_DEBUG以减小二进制体积和提升性能。

5.4 部署与分发

问题8：如何为不同平台打包发布？

• 解决：
  • Windows：使用windeployqt工具。在构建完成后，进入构建目录，执行<Qt_install_path>/bin/windeployqt.exe --release <path_to_your_executable>。它会自动复制所有依赖的Qt库、插件和QML文件。你可以将其与NSIS、Inno Setup或WiX工具集结合制作安装包。
  • macOS：使用macdeployqt工具。类似地，<Qt_install_path>/bin/macdeployqt <YourApp.app> -always-overwrite。它会处理Framework的嵌入和签名（需要开发者证书）。
  • Linux：情况更复杂，依赖系统库。可以使用linuxdeployqt（第三方工具），或者配合AppImage、Flatpak、Snap等容器化技术进行分发。在CMake中，通过install命令精细控制安装内容，是制作Linux包（如deb, rpm）的基础。

实操心得：部署是CMake+Qt项目的最后一步，也是最容易出问题的一步。我强烈建议在项目的早期就建立一套自动化的部署脚本（比如用Python或Shell编写），集成到CI/CD流程中。每次打发布包时，脚本自动执行windeployqt/macdeployqt、收集文件、压缩打包。这能避免手动操作带来的遗漏和错误。另外，一定要在“干净”的虚拟机或目标系统上测试部署后的程序，确保没有隐藏的依赖。