build(cmake): refactor Qt version compatibility

[re2zero]

• Add Qt auto-detection using find_package(QT NAMES Qt6 Qt5)
• Separate debian/control files:
  • control: V25 (Qt6) with explicit qt6-base-dev, libdtk6*-dev deps
  • control.1: V20 (Qt5) with explicit qtbase5-dev, libdtk*-dev deps

This enables seamless building on both V25 (Qt6) and V20 (Qt5) systems without version-specific conditional dependencies.

Log: 分离Qt5/Qt6构建配置，支持V25/V20双版本
PMS: https://pms.uniontech.com/task-view-386321.html

[deepin-ci-robot]

deepin pr auto review

这份代码变更主要涉及将构建系统从同时支持 Qt5 和 Qt6 的双版本模式，转变为明确指定使用 Qt6 的单一版本模式（同时保留了 Qt5 的旧版配置文件）。下面是对代码的详细审查和改进建议：

1. 语法逻辑审查

debian/control

• 变更内容：移除了 qtbase5-dev 等依赖项，仅保留 Qt6 相关的依赖（如 qt6-base-dev）。
• 逻辑问题：
  • 移除了 | (OR) 逻辑依赖，强制要求 Qt6。这意味着该软件包将无法在仅安装了 Qt5 的旧系统上构建。
  • 潜在风险：如果目标发行版（如较旧的 UOS 或 Debian 版本）的仓库中没有提供 Qt6 版本的 DTK (libdtk6widget-dev)，构建将会直接失败。

debian/control.1

• 新增文件：这是一个新文件，内容实际上是变更前的 debian/control，完全基于 Qt5。
• 逻辑问题：
  • 冗余文件：在标准的 Debian 打包流程中，debian/control.1 不是一个标准文件。它看起来像是一个备份文件。
  • 建议：如果这是为了保留 Qt5 的构建方案，应该使用 Git 分支或单独的目录来管理，而不是提交一个名为 .1 的文件到仓库中。如果这只是一个备份，应该将其加入 .gitignore。

debian/rules

• 变更内容：增加了 detect_qt_version 逻辑，并在 dh_auto_configure 中显式传递 QT_DIR。
• 逻辑问题：
  • Qt 检测逻辑与 control 文件冲突：debian/rules 中编写了检测 Qt5/Qt6 的逻辑（ifneq (,$(shell which qmake6 ...))），但 debian/control 中已经移除了 Qt5 的构建依赖。这意味着在标准的构建环境中（如 pbuilder 或 sbuild），即使检测到 Qt5，构建也会失败，因为缺少 qtbase5-dev 等包。
  • 变量覆盖：QT_DIR 的硬编码逻辑可能会干扰 CMake 的 find_package 机制。CMake 通常能自动找到 Qt 的 Config.cmake 文件，显式指定路径有时会导致跨架构（如 amd64 vs arm64）构建时的路径问题。
  • export QT_SELECT=5：这行代码被保留了下来，但后续逻辑优先检测 Qt6。这会导致环境变量和实际检测逻辑不一致，容易引起混淆。

src/CMakeLists.txt

• 变更内容：使用 find_package(QT NAMES Qt6 Qt5 ...) 自动检测 Qt 版本，并根据 QT_VERSION_MAJOR 设置 DTK 版本。
• 逻辑问题：
  • 与 debian/control 的不一致：CMakeLists.txt 尝试查找 Qt6 或 Qt5（NAMES Qt6 Qt5），但 debian/control 仅允许安装 Qt6。如果构建环境只有 Qt5，find_package 会失败，且报错信息可能不如 debian/control 的依赖检查直接。
  • DTK 版本映射：当 QT_VERSION_MAJOR 为 5 时，DTK_VERSION_MAJOR 被设置为空字符串 ("")。后续代码 find_package(Dtk${DTK_VERSION_MAJOR} ...) 会变成 find_package(Dtk ...)。这依赖于 CMake 的 DtkConfig.cmake 文件是否支持不带版本号的调用，存在风险。通常应该显式设置为 5。

2. 代码质量

• 注释与可读性：
  • debian/rules 中的注释 # hardcode this if want to force build with sepecific Qt version 拼写错误（sepecific -> specific）。
  • debian/rules 的 detect_qt_version 宏定义虽然增加了灵活性，但在单一 Qt6 依赖策略下显得多余且增加了维护复杂度。
• 一致性：
  • debian/control 和 debian/control.1 内容高度重复，违反了 DRY (Don't Repeat Yourself) 原则。建议使用 debian/control 作为唯一源，利用 dpkg-buildpackage 的条件构建特性（如通过环境变量或构建 Profile）来处理不同 Qt 版本的依赖，而不是维护两个文件。

3. 代码性能

• 构建性能：
  • debian/rules 中添加了 --parallel，这是一个好的改进，可以利用多核 CPU 加速构建。
  • debian/rules 中的 shell which qmake6 命令会在 make 解析阶段执行，虽然开销很小，但在复杂的构建系统中应尽量减少 shell 命令的调用。

4. 代码安全

• 路径注入风险：
  • 在 debian/rules 中直接构造路径 QT_DIR="/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/Qt6"。虽然使用了 DEB_HOST_MULTIARCH，但在某些非标准安装或交叉编译场景下，这个路径可能不正确，导致构建失败或链接了错误的库。
• 依赖完整性：
  • debian/control 中移除了 Qt5 依赖，如果上游代码或 DTK 库在某些回退场景下仍依赖 Qt5 的符号或工具，可能会导致运行时错误。

改进建议

1. 统一构建策略：

   • 如果项目决定全面转向 Qt6，应彻底清理 debian/rules 中关于 Qt5 检测的遗留代码，移除 export QT_SELECT=5，确保逻辑清晰。
   • 删除 debian/control.1 文件，避免仓库污染。

2. 修复 CMakeLists.txt 的 DTK 版本逻辑：

   • 修改 src/CMakeLists.txt，确保 DTK 版本号明确：

     if (QT_VERSION_MAJOR MATCHES 6)
         set(DTK_VERSION_MAJOR 6)
     else()
         set(DTK_VERSION_MAJOR 5) # 显式设置为5，而不是空字符串
     endif()

3. 简化 debian/rules：

   • 移除 detect_qt_version 宏，既然 debian/control 已经限定了 Qt6，CMake 也能自动找到 Qt6，不需要在 debian/rules 层面重复检测并传递 QT_DIR。
   • 简化后的 override_dh_auto_configure：

     override_dh_auto_configure:
     	dh_auto_configure -- \
     		-DCMAKE_BUILD_TYPE=Release \
     		-DVERSION=$(DEB_VERSION_UPSTREAM) \
     		-DCMAKE_INSTALL_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)

4. 处理多版本支持（如果确实需要）：

   • 如果必须同时支持 Qt5 和 Qt6（例如为了兼容旧系统），建议使用 Debian 的构建 Profile 功能。
   • 在 debian/control 中使用 Package Build Profiles（例如 <profile.qt5>）来标记可选依赖，而不是使用 | 符号混合依赖，或者维护两个独立的分支（debian/qt5 和 debian/qt6）。

5. 拼写修正：

   • 修正 debian/rules 中的注释拼写错误。

总结来说，这次修改在方向上（转向 Qt6）是合理的，但在执行层面存在逻辑不一致（rules 检测 vs control 依赖）、文件冗余（control.1）和潜在的健壮性问题（DTK 版本空字符串）。建议进行上述清理和规范化操作，以提高构建系统的可维护性和可靠性。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lzwind, re2zero

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[re2zero]

/merge