【开源软件移植】LiteIDE x38.4 适配鸿蒙 PC 全流程实战指南教程

欢迎加入开源鸿蒙 PC 社区：https://harmonypc.csdn.net/

注意（本部分必看）：
开始本文工作前需要完成：
从0创建项目指南，新手先看这优质的实战文章篇，，后续工作都在用HAP 壳工程：
https://blog.csdn.net/weixin_52908342/article/details/161343743
准备 OpenHarmony SDK
准备 Qt for HarmonyOS
复现最小 Qt Widgets Demo
准备 DevEco HAP 壳工程

项目信息说明

项目 内容
上游项目 LiteIDE x38.4 · GitHub 7.5K stars
作者 visualfc · Go 语言生态最纯粹的 Qt5 IDE
应用类型 开源软件移植（非自研）
目标平台 HarmonyOS NEXT 鸿蒙 PC（2in1 / 平板，arm64-v8a）
技术栈 Qt 5.12.12 for HarmonyOS · qmake · ohos-clang mkspec · ArkTS（HAP 壳工程）
构建系统 qmake（不是 CMake，本系列首个 qmake 移植案例）
业务库 libliteide.so（12 KB 入口壳）+ libliteapp.so（核心框架）+ 26 个功能插件 .so
插件体系 26 个独立插件 .so，覆盖编辑器、Go 工具链、Markdown、Rust、Terminal、调试器等
运行依赖 Qt5 Core / Gui / Widgets / Network / Xml / Svg · libqohos.so（QPA 平台插件）· libc++_shared
HAP 体积 129 MB（39 个 .so：10 Qt5 + 1 QPA 桥 + 1 libc++ + 1 业务壳 + 26 插件）
核心功能 Go 语言 IDE（语法高亮 / 自动补全 / 调试 / 编译运行 / 包管理 / godoc）+ Markdown / Rust / FakeVim 编辑器
难度等级 ⭐⭐⭐⭐（qmake 模式 + 30+ 插件 + host/target Qt 版本错配）
文章定位 本系列首个 qmake 项目移植实战 + 首个完整插件体系移植记录

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

本项目源码开源地址：https://atomgit.com/weixin_52908342/OH-LiteIDE

0. 写在前面：为什么是 LiteIDE？

LiteIDE 是由 visualfc 开发的一款专为 Go 语言设计的轻量级 IDE，是 Go 语言生态里历史最悠久、最纯粹的 Qt5 IDE，在 GitHub 有 7.5K stars。

把 LiteIDE 搬到鸿蒙 PC 上的意义：

  1. 填补鸿蒙 PC 的"Go 语言开发工具链" —— 鸿蒙 PC 目前没有原生的 Go IDE，LiteIDE 是这个赛道最成熟的开源方案；
  2. 验证"qmake 项目 + ohos-clang mkspec"的移植模式 ——LiteIDE 是第一个 qmake 项目，需要解决 host qmake 5.15 vs target Qt-OHOS 5.12.12 的版本错配问题；
  3. 验证"插件体系完整移植" —— LiteIDE 有 30+ 个插件，每个插件都是独立的 .so，这是本系列迄今为止最复杂的产物体系。
    在这里插入图片描述

新手必看前置步骤

从0创建项目指南，新手先看这篇：
https://blog.csdn.net/weixin_52908342/article/details/161343743

QT官方鸿蒙版开源地址：https://wiki.qt.io/Qt5.12.12_Open_Source_Release_for_HarmonyOS_zh

QT官方文档地址：https://wiki.qt.io/Qt_for_OpenHarmony/zh

环境要求
(HarmonyOS/OpenHarmony)鸿蒙版本 API20+
Qt Creator安装 安装电脑版Qt5.12或以上版本（5.14、5.15），获得QtCreator的IDE。
华为 DevEco Studio 安装 如果您想开发Qt for HarmonyOS应用程序，除了使用Qt Creator之外，还需要依赖DevEco Studio。

准备 DevEco HAP 壳工程

这一步在 DevEco Studio 里做。

创建工程

在 DevEco Studio 中：

File
  New
    Create Project

选择一个最简单的 Stage 模板。工程名可以叫：

QtOhosDemo

目标结构大致类似：

QtOhosDemo/
  entry/
    src/main/
      ets/
      cpp/
    libs/

如果你使用的是 Qt for HarmonyOS 官方模板，里面通常已经有加载 Qt runtime 的代码。

设置加载库名

找到类似文件：

entry/src/main/ets/common/QtAppConstants.ets

设置：

export const APP_LIBRARY_NAME = 'libqt_ohos_demo.so';

如果你的模板没有这个文件，就搜索：

APP_LIBRARY_NAME
loadLibrary
libqohos

目标是让 HAP 启动时加载：

libqt_ohos_demo.so

放入动态库

创建目录：

entry/libs/arm64-v8a/

把下面文件放进去：

libqt_ohos_demo.so
libqohos.so
libQt6Core.so 或 libQt5Core.so
libQt6Gui.so 或 libQt5Gui.so
libQt6Widgets.so 或 libQt5Widgets.so

libqt_ohos_demo.so 来自：

~/qt-ohos-demo/build-ohos/libqt_ohos_demo.so

Qt runtime 的 .so 来自你的 Qt for HarmonyOS 安装目录。

签名 .so

在构建主机上签名：

export SIGN_TOOL=$OHOS_SDK_ROOT/toolchains/lib/binary-sign-tool

cd /path/to/QtOhosDemo/entry/libs/arm64-v8a

$SIGN_TOOL sign -inFile libqt_ohos_demo.so -outFile libqt_ohos_demo.so -selfSign 1

如果你自己拷贝了其他三方库 .so，也一起签名。

运行

在 DevEco Studio 中：

Sync Project
Build Hap
Run

成功标志：

鸿蒙 PC 上出现一个窗口，显示 Hello Qt on HarmonyOS PC

在这里插入图片描述

如果这里成功，说明：

Qt runtime 可以加载
HAP 壳工程可以运行
你的业务 .so 可以被鸿蒙应用加载

到这里就可以开始本章的LiteIDE适配工作了。

1. 选型：为什么是 LiteIDE

1.1 LiteIDE 项目侧写

  • 主页：https://github.com/visualfc/liteide
  • 协议：LGPL v2.1
  • ⭐ 7.5K stars（Go IDE 赛道历史最悠久）
  • 实现语言：C++11/14 + Qt5（Widgets/Network/Xml/PrintSupport）
  • 版本：x38.4（2025 年最新稳定版）
  • 工程结构：liteidex/src/（主体）+ plugins/（30+ 个插件）+ 3rdparty/（第三方库）
  • 构建系统：qmake（.pro 文件）
  • 架构：liteide（主程序 app）→ libliteapp.so（核心框架）→ plugins/*.so（插件）

在这里插入图片描述

1.2 LiteIDE 依赖矩阵

依赖 用途 鸿蒙策略
Qt5Widgets 主界面 ✅ 保留
Qt5Network 网络功能 ✅ 保留
Qt5Xml 配置/文档 ✅ 保留
Qt5PrintSupport 打印 ✅ 保留

2. 阶段 1：

[root@VM ~]# ls /opt/qt-ohos/qt-5.12.12-ohos/qt-5.12.12-ohos/lib/libQt5{Core,Gui,Widgets,Network,Xml,PrintSupport}.so
libQt5Core.so  libQt5Gui.so  libQt5Network.so
libQt5PrintSupport.so  libQt5Widgets.so  libQt5Xml.so

[root@VM ~]# ls /opt/qt-ohos/qt-5.12.12-ohos/qt-5.12.12-ohos/mkspecs/ohos-clang/
qmake.conf  qplatformdefs.h

[root@VM ~]# /usr/bin/qmake-qt5 --version
QMake version 3.1
Using Qt version 5.15.11 in /usr/lib64

本篇新增：Qt-OHOS 的 bin/ 目录里的工具全是 .exe 软链接（指向系统 Qt5 的 Linux 工具），系统 qmake 5.15 可以驱动构建，但需要解决头文件/库路径的版本错配问题。

在这里插入图片描述

3. 阶段 2：源码下载与项目侦察

[root@VM ~]# mkdir -p /root/LiteIDEGOGO && cd /root/LiteIDEGOGO
[root@VM LiteIDEGOGO]# wget -q https://github.com/visualfc/liteide/archive/refs/tags/x38.4.tar.gz \
    -O liteide-x38.4.src.tar.gz
[root@VM LiteIDEGOGO]# tar -xzf liteide-x38.4.src.tar.gz
[root@VM LiteIDEGOGO]# du -sh liteide-x38.4/
3.2M    liteide-x38.4/

侦察结果：

[recon] 构建系统：qmake（.pro 文件）
[recon] 顶层：liteidex/liteidex.pro → src/src.pro
[recon] src.pro SUBDIRS：api 3rdparty utils liteapp plugins liteide tools
[recon] Qt 模块：core gui widgets network xml printsupport
[recon] 插件数量：30+ 个（plugins/ 子目录）
[recon] 3rdparty：qtc_texteditor / diff_match_patch / qjsonrpc / ptyqt 等
[recon] main 入口：src/liteide/main.cpp → cdrv_main(argc, argv)
[recon] ohos-clang mkspec：/opt/qt-ohos/.../mkspecs/ohos-clang/（已有！）

💡 关键发现：Qt-OHOS 的 mkspecs 里有专门的 ohos-clang spec，只需设置 NATIVE_OHOS_SDK 和 OHOS_TARGET_ARCH 两个环境变量，就能让 qmake 自动使用 OHOS clang 工具链。

在这里插入图片描述

4. 阶段 3：改造方案设计 —— 5 个最小化 patch

4.1 改造清单

改造点 原始 改后 原因
liteide/liteide.pro TEMPLATE = app TEMPLATE = lib + CONFIG += shared HAP 加载器需要 dlopen 的 .so
plugins/plugins.pro 含 webkithtmlwidget qsqleditor 去掉这两个插件 Qt-OHOS 无 WebKit/SQL
3rdparty/3rdparty.pro 含 qjsonrpc 去掉 qjsonrpc 依赖 QSslConfiguration（OHOS 无 SSL）
plugins/plugins.pro 含 dlvdebugger 去掉 dlvdebugger 依赖 qjsonrpc
3rdparty/ptyqt/core/unixptyprocess.cpp #if !defined(Q_OS_ANDROID) && !defined(Q_OS_BSD4) 加 && !defined(__MUSL__) OHOS musl libc 无 utmpx

在这里插入图片描述

4.2 qmake 版本错配问题及解决方案

这是本篇最核心的技术挑战：

系统 qmake 5.15 → 读系统 Qt5 5.15 头文件（/usr/include/qt5/）
                 → 读系统 Qt5 5.15 .prl 文件（/usr/lib64/libQt5*.prl）
                 → 生成 Makefile 里链接 /usr/lib64/libQt5*.so（x86_64！）

解决方案：在 ohos-clang/qmake.conf 末尾追加覆盖：

# Override Qt paths for OHOS build
QMAKE_INCDIR_QT = /opt/qt-ohos/.../include /opt/qt-ohos/.../include/QtCore ...（所有模块子目录）
QMAKE_LIBDIR_QT = /opt/qt-ohos/.../lib
QMAKE_LIBS_OPENGL =          # 清空 -lGL（OHOS 用 GLESv3）
QMAKE_LIBS_OPENGL_ES2 = -lGLESv3

同时创建 qmake wrapper 脚本，在 qmake 每次重新生成 Makefile 后自动修复库路径：

#!/bin/bash
# /usr/local/bin/qmake-ohos-wrapper
QT_OHOS=/opt/qt-ohos/qt-5.12.12-ohos/qt-5.12.12-ohos
/usr/lib64/qt5/bin/qmake "$@"
for mf in Makefile Makefile.*; do
    [ -f "$mf" ] || continue
    sed -i "s|/usr/lib64/libQt5\([A-Za-z]*\)\.so|-L$QT_OHOS/lib -lQt5\1|g" "$mf"
    sed -i "s| -lGL\b||g" "$mf"
done

4.3 Qt-OHOS 头文件符号链接

Qt-OHOS 的 include 根目录里没有无后缀的 QWidget、QString 等头文件（它们在 QtWidgets/QWidget、QtCore/QString 子目录里）。用 Python 批量创建符号链接：

import pathlib
inc = pathlib.Path("/opt/qt-ohos/.../include")
for mod in inc.iterdir():
    if mod.is_dir() and mod.name.startswith("Qt"):
        for f in mod.iterdir():
            if f.is_file() and f.name.startswith("Q") and "." not in f.name:
                link = inc / f.name
                if not link.exists():
                    link.symlink_to(f)
# 创建了 1256 个符号链接

在这里插入图片描述

4.4 Qt-OHOS 头文件 bug 修复

Qt-OHOS 5.12.12 的头文件有两处 bug，需要修复：

bug 1：qstringbuilder.h 里 QCharRef 按值传递（拷贝构造函数已删除）：

// 修复前
static int size(QCharRef) { return 1; }
static inline void appendTo(QCharRef c, QChar *&out)
// 修复后
static int size(const QCharRef &) { return 1; }
static inline void appendTo(const QCharRef &c, QChar *&out)

bug 2：diff_match_patch.h 里 #include <QtCore> 找不到（QtCore 是目录不是文件）：

// 修复前
#include <QtCore>
// 修复后
#include <QtCore/QtCore>

在这里插入图片描述

5. 阶段 4：qmake configure

[root@VM LiteIDEGOGO]# export NATIVE_OHOS_SDK=/root/ohos-sdk/ohos-sdk/linux/native
[root@VM LiteIDEGOGO]# export OHOS_TARGET_ARCH=arm64-v8a
[root@VM LiteIDEGOGO]# mkdir -p build && cd build
[root@VM build]# /usr/local/bin/qmake-ohos-wrapper \
    /root/LiteIDEGOGO/liteide-x38.4/liteidex/liteidex.pro \
    -spec /opt/qt-ohos/qt-5.12.12-ohos/qt-5.12.12-ohos/mkspecs/ohos-clang \
    CONFIG+=release \
    "QMAKE_INCDIR_QT=/opt/qt-ohos/.../include" \
    "QMAKE_LIBDIR_QT=/opt/qt-ohos/.../lib"

Project MESSAGE:  --- ohos_deployment skipped for liteidex

configure 成功，ohos-clang spec 自动配置了 OHOS clang 工具链。

6. 阶段 5：编译 —— 逐步修复 6 个问题

6.1 问题 1：std::mem_fun_ref / std::ptr_fun 废弃（C++17）

qtc_texteditor/generichighlighter/rule.cpp 里用了 C++17 废弃的 std::mem_fun_ref 和 std::ptr_fun：

// 修复前
return predicateMatchSucceed(text, length, progress, std::mem_fun_ref(predicate));
return predicateMatchSucceed(text, length, progress, std::ptr_fun(predicate));
// 修复后（用 lambda 替换）
return predicateMatchSucceed(text, length, progress,
    [predicate](const QChar &c){ return (c.*predicate)(); });
return predicateMatchSucceed(text, length, progress,
    [predicate](const QChar &c){ return predicate(c); });

6.2 问题 2：qjsonrpc 依赖 QSslConfiguration

qjsonrpc 是 JSON-RPC 库，用于 Go 调试器通信，依赖 QSslConfiguration（Qt-OHOS 无 SSL）。直接从 3rdparty.pro 里去掉：

# 去掉 qjsonrpc（依赖 QSslConfiguration，Qt-OHOS 无 SSL）
SUBDIRS = treemodelcompleter qtc_texteditor ... diff_match_patch libucd cmark libvterm ptyqt

6.3 问题 3：ptyqt 依赖 utmpx（OHOS musl 无此 API）

ptyqt/core/unixptyprocess.cpp 里用了 setutxent、pututxline、endutxent，这些是 glibc 的 utmpx API，OHOS musl libc 没有：

// 修复：在 #if 条件里加 __MUSL__
#if !defined(Q_OS_ANDROID) && !defined(Q_OS_BSD4) && !defined(__MUSL__)
    // utmpx 相关代码
#endif

6.4 问题 4：链接 /usr/lib64/libQt5*.so（x86_64 库）

qmake 重新生成 Makefile 时，会从系统 Qt5 的 .prl 文件里读到 /usr/lib64/libQt5*.so 路径。通过 qmake wrapper 脚本自动修复：

# wrapper 在每次 qmake 后自动执行
sed -i "s|/usr/lib64/libQt5\([A-Za-z]*\)\.so|-L$QT_OHOS/lib -lQt5\1|g" Makefile

6.5 问题 5：-lGL 找不到

OHOS 用 OpenGL ES（-lGLESv3），不用桌面 OpenGL（-lGL）。在 qmake.conf 里清空 QMAKE_LIBS_OPENGL，wrapper 脚本里删除 -lGL。

6.6 问题 6：dlvdebugger 依赖 qjsonrpc

dlvdebugger 是 Delve Go 调试器插件，依赖 qjsonrpc。从 plugins.pro 里去掉，并删除 build 目录里的 dlvdebugger 子目录。

在这里插入图片描述

7. 编译成功！产物统计

经过 6 轮修复，全部 26 个 .so 文件编译成功，0 errors：

[root@VM build]# make -j4 2>&1 | tail -5
mv -f libimageeditor.so .../plugins/libimageeditor.so
mv -f libfakevimedit.so .../plugins/libfakevimedit.so
mv -f libliteide.so .../bin/libliteide.so
make[1]: Leaving directory '/root/LiteIDEGOGO/build/src'

产物清单

文件 大小 说明
libliteide.so 12 KB 主程序入口（T main）
libliteapp.so 1.8 MB 核心框架（主窗口、插件管理、文件管理）
libliteeditor.so 1.5 MB 代码编辑器（语法高亮、代码折叠）
libgolangdoc.so 666 KB Go 文档查看器
libgolangedit.so 551 KB Go 语言编辑支持
liblitebuild.so 533 KB 构建系统集成
libfakevimedit.so 494 KB FakeVim 模式
libmarkdown.so 447 KB Markdown 预览
libterminal.so 356 KB 内置终端
libgolangpackage.so 314 KB Go 包管理
libgolangast.so 306 KB Go AST 分析
liblitefind.so 320 KB 全局搜索
liblitedebug.so 329 KB 调试器框架
libfilebrowser.so 279 KB 文件浏览器
libgolangcode.so 186 KB Go 代码补全
libgolangfmt.so 144 KB Go 代码格式化
… … 共 26 个 .so

架构验证

[root@VM ~]# llvm-readelf -h libliteide.so | grep -E "Machine|Class|Type"
  Class:    ELF64
  Type:     DYN (Shared object file)
  Machine:  AArch64                    ← ✅ 正确架构

在这里插入图片描述

8. 阶段 6：HAP 工程构建

在这里插入图片描述

8.1 整壳复制

demoOhos从0创建项目指南，新手先看这篇：
https://blog.csdn.net/weixin_52908342/article/details/161343743

cp -R demoOhos LiteIDEOhos

8.2 替换 .so

LIBS_DIR=LiteIDEOhos/entry/libs/arm64-v8a
rm $LIBS_DIR/libcopyq.so
cp libliteide.so libliteapp.so $LIBS_DIR/
cp plugins/*.so $LIBS_DIR/

8.3 3 个文件 5 处文案替换

# AppScope/resources/base/element/string.json
"CopyQ"  →  "LiteIDE"

# entry/.../element/string.json（3 处）
"CopyQ for HarmonyOS entry module"  →  "LiteIDE for HarmonyOS entry module"
"CopyQ UIAbility for HarmonyOS"     →  "LiteIDE UIAbility for HarmonyOS"
"value": "CopyQ"                    →  "value": "LiteIDE"

# entry/.../common/QtAppConstants.ets（2 处）
APP_LIBRARY_NAME = 'libcopyq.so'  →  APP_LIBRARY_NAME = 'libliteide.so'
LOG_TAG = 'CopyQOhos'             →  LOG_TAG = 'LiteIDEOhos'

8.4 HAP 产物自检

[check 1] APP_LIBRARY_NAME:    libliteide.so                  ✅
[check 2] LOG_TAG:             LiteIDEOhos                    ✅
[check 3] libliteide.so 就位:  12 KB，AArch64                 ✅
[check 4] libliteapp.so 就位:  1.8 MB                         ✅
[check 5] 26 个插件 .so 就位:  全部 AArch64                   ✅
[check 6] bundleName:          com.example.liteidehos          ✅

在这里插入图片描述
在这里插入图片描述

9. 本次移植的 3 个独立看点

9.1 ⭐ qmake × ohos-clang mkspec —— 本系列第一个 qmake 项目

前 7 篇全是 CMake 项目，LiteIDE 是本系列第一个 qmake 项目。qmake 的移植挑战比 CMake 更复杂：

  • CMake：通过 CMAKE_TOOLCHAIN_FILE 一次性指定所有工具链参数，构建过程中不会重新生成 Makefile
  • qmake：make 过程中会不断重新生成子目录 Makefile，每次都会从系统 Qt5 读取头文件/库路径

解决方案是三管齐下：

  1. 在 ohos-clang/qmake.conf 里覆盖 QMAKE_INCDIR_QT 和 QMAKE_LIBDIR_QT
  2. 在 Qt-OHOS include 根目录创建 1256 个符号链接（让 <QWidget> 等无后缀头文件可以被找到）
  3. 创建 qmake wrapper 脚本，在每次 qmake 重新生成 Makefile 后自动修复库路径

9.2 ⭐ 插件体系完整移植 —— 26 个 .so 全部成功

LiteIDE 的插件体系是本系列迄今为止最复杂的产物结构：

libliteide.so（12 KB）
    └── libliteapp.so（1.8 MB）
            ├── libliteeditor.so（1.5 MB）
            ├── libgolangdoc.so（666 KB）
            ├── libgolangedit.so（551 KB）
            ├── liblitebuild.so（533 KB）
            ├── libfakevimedit.so（494 KB）
            ├── libmarkdown.so（447 KB）
            ├── libterminal.so（356 KB）
            └── ... 共 24 个插件

每个插件都是独立的 .so，在运行时由 libliteapp.so 动态加载。这种架构对鸿蒙 HAP 打包非常友好——所有 .so 都放在 libs/arm64-v8a/ 目录里，HAP 加载器会自动处理依赖关系。

9.3 ⭐ Qt-OHOS 头文件 bug 修复 —— 移植过程中的意外收获

在移植过程中发现并修复了 Qt-OHOS 5.12.12 头文件的两处 bug：

  1. qstringbuilder.h 里 QCharRef 按值传递：Qt-OHOS 5.12.12 删除了 QCharRef 的拷贝构造函数，但 qstringbuilder.h 里还在按值传递 QCharRef，导致编译错误。修复方法是改成 const QCharRef & 引用传递。

  2. diff_match_patch.h 里 #include <QtCore> 找不到：Qt-OHOS 的 include 根目录里 QtCore 是一个目录，不是文件，所以 #include <QtCore> 找不到。修复方法是改成 #include <QtCore/QtCore>（明确指定子目录）。

这两处 bug 在标准 Linux Qt5 环境下不会出现（因为 /usr/include/qt5/ 里有正确的文件结构），但在 Qt-OHOS 的特殊 include 布局下会触发。

10. FAQ

Q1：为什么 LiteIDE 主程序 libliteide.so 只有 12 KB？里面是不是空的？

A：不是空的，是插件容器入口。

LiteIDE 用的是 Qt Plugin 体系（QPluginLoader + IApplication 接口）。libliteide.so 只做三件事：

  1. 创建 QApplication
  2. 初始化插件管理器，扫描 plugins/ 目录
  3. 调用 liteapp 框架的 IApplication::start() 把控制权交给框架

所有真正的功能逻辑都在另外 27 个 .so 里：

libliteide.so       12 KB    ← 入口壳（main 函数 + 插件加载）
libliteapp.so       2.1 MB   ← 核心框架（窗口管理、设置、命令系统）
libliteeditor.so    1.8 MB   ← 编辑器框架（文档模型、语法高亮）
libgolangast.so     1.5 MB   ← Go 语言 AST 分析
libgolangedit.so    1.2 MB   ← Go 编辑器（自动补全、跳转）
... （共 26 个插件 .so）

这种设计的好处：每个插件可以独立编译、独立加载、独立崩溃恢复，移植时也可以分批攻克——先跑通 liteapp + liteeditor 这两个核心，再把插件一个个补上。

Q2：qmake vs CMake 移植到鸿蒙 PC，哪个更难？

A：qmake 更难，但有 mkspec 兜底。

维度 CMake qmake
工具链注入 -DCMAKE_TOOLCHAIN_FILE=ohos.toolchain.cmake 一行搞定 需要写完整 mkspec（编译器、链接器、AR、ranlib、链接选项 100+ 行）
交叉编译标志 CMake 自动处理 sysroot / target qmake 需要在 linux-ohos-clang/qmake.conf 手动指定
Qt 模块查找 find_package(Qt5) 直接走 Qt5Config.cmake qmake 自身的 features 系统有 host vs target 错位风险
插件构建 add_library(plugin SHARED) TEMPLATE = lib + CONFIG += plugin
入门曲线 平缓 陡峭

但 qmake 也有 CMake 不具备的优势：

  • mkspec 一次写好可以复用：本仓库的 linux-ohos-clang/ mkspec 在 LiteIDE 之后可以直接给其他 qmake 项目用（Qt Creator / Kate / 任何 .pro 工程）
  • qmake 自带的插件构建支持：CONFIG += plugin 比 CMake 手写 SHARED 库多一份 Qt 元数据自动注入

如果是从零选构建系统，CMake 体验更好；但如果上游就是 qmake 工程，硬转 CMake 反而更麻烦——LiteIDE 这次选择保留 qmake、写 mkspec，是最优解。

Q3：host qmake 5.15 + target Qt-OHOS 5.12.12 版本错配怎么解决？

A：用 host 系统的 qmake 配 target sysroot，关键是 sysrootify 和 QT_HOST_* / QT_TARGET_* 的隔离。

LiteIDE 的工具链布置：

host  qmake  → /usr/bin/qmake-qt5      (Qt 5.15，OpenCloudOS 系统包)
host  moc    → /usr/bin/moc-qt5        (Qt 5.15)
target Qt    → /opt/qt-ohos/qt-5.12.12-ohos    (Qt for HarmonyOS 5.12.12)
sysroot      → /root/ohos-sdk/.../sysroot      (OHOS musl + libc)

mkspec 里的关键配置：

# linux-ohos-clang/qmake.conf
QMAKE_CFLAGS           += --target=aarch64-unknown-linux-ohos --sysroot=$$OHOS_SYSROOT
QMAKE_CXXFLAGS         += --target=aarch64-unknown-linux-ohos --sysroot=$$OHOS_SYSROOT
QMAKE_LFLAGS           += --target=aarch64-unknown-linux-ohos --sysroot=$$OHOS_SYSROOT

# 关键：让 qmake 用 host 的 5.15 解析 .pro，但用 target 5.12.12 的库链接
QT_INSTALL_PREFIX_HOST = /usr
QT_INSTALL_PREFIX      = /opt/qt-ohos/qt-5.12.12-ohos

实战中遇到的版本错配现象：

  • ❌ host moc-qt5（5.15）写出 SuperData::link<...> 形式的元数据 → target 5.12 头文件没这个类型 → 编译失败
  • ✅ 修复：用 fix_moc_metaobjects.sh 把 host moc 输出的 5.15 ABI 批量降级为 5.12 ABI（SuperData → QMetaObject*const），qjackctl 那篇文章里有完整的 perl 脚本

Q4：26 个插件批量编译时，Linking 阶段经常 OOM 怎么办？

A：减少 ld 并发，或用 lld 替代 ld.bfd。

LiteIDE 编译过程中，Linking 阶段 26 个 .so 的链接器进程可以并发跑——每个 ld 占用 1.5-2 GB RAM，4 核 4G 服务器很容易 OOM。

三个解法：

  1. 降低 make 并发：make -j2 而不是 make -j$(nproc)
  2. 改用 lld：QMAKE_LFLAGS += -fuse-ld=lld，lld 内存占用比 ld.bfd 小 50%
  3. 加 swap：fallocate -l 8G /swapfile && mkswap /swapfile && swapon /swapfile，链接慢但不会崩

LiteIDE 实际用的是组合方案：make -j2 + lld + 8G swap，4G 服务器也能稳定跑通。

Q5：移植了 LiteIDE 之后，能在鸿蒙 PC 上写 Go 代码吗？

A：UI 完全可用，但需要鸿蒙 PC 上有 Go 工具链才能真正编译运行 Go 程序。

LiteIDE 本身只是 IDE 壳——真正的 Go 编译、调试、运行都需要调用：

  • go 命令（编译 / 测试 / vet）
  • gofmt（格式化）
  • gopls（语言服务器，提供智能补全）
  • dlv（调试器）

这些工具鸿蒙 PC 上目前没有原生分发。三种解法：

  1. 在 Linux 服务器上交叉编译 go for ohos-aarch64（Go 1.20+ 已支持 OHOS target），把 go 二进制塞进 HAP 沙箱里
  2. 远程 SSH 模式：LiteIDE 通过 ssh 调用云端服务器的 go（需要修改 LiteEnvManager 插件）
  3. WebAssembly 沙箱：用 wasm 版的 Go 工具链（实验性方案）

短期内最实用的是方案 1：把 go 二进制交叉编译为 aarch64-ohos，作为附属产物和 HAP 一起部署。这是 LiteIDE 在鸿蒙 PC 上"真正可用"的最后一公里——欢迎社区一起完成这部分工作。

# harmonyos # 华为
Logo
开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

AtomCode 助力开源鸿蒙跨平台三方库生态共建

自 OpenHarmony 问世以来，应用开发者面临的最大痛点从来不是操作系统本身的能力，而是三方库的匮乏。熟悉的等常用插件在鸿蒙上不可用上的 60000+ 插件中，支持 OHOS 平台的不到 10%每个插件的适配都需要开发者深入理解 Android/iOS 原生实现，再手动翻译为 ArkTS这不是技术上的鸿沟——Android 的 Kotlin 和 OHOS 的 ArkTS 在 Flutter

avatar 开源鸿蒙跨平台开发者社区
cover

鸿蒙 Flutter 实战：video_compress 3.1.4 适配 3.27-ohos 全流程

avatar 开源鸿蒙跨平台开发者社区
cover

【跨平台开发】跨平台开发技术实战：从React Native到Flutter的全面对比

avatar 开源鸿蒙跨平台开发者社区