[鸿蒙PC命令行移植适配]移植rust三方库grex到鸿蒙PC的完整实践
本文介绍了正则表达式生成工具grex及其在鸿蒙PC平台的适配过程。grex能够根据测试用例自动生成匹配的正则表达式,支持命令行和Rust/Python集成。文章详细说明了鸿蒙PC开发环境配置要求,包括OpenHarmony SDK安装、目录结构及环境变量设置,并提供了Linux/macOS系统下的配置示例。同时,文中列出了系列教程索引,涵盖从环境搭建到构建执行的完整流程,以及Rust库适配扩展框架
欢迎加入【开源鸿蒙PC社区】,一起共建鸿蒙化C/C++三方库生态。
前言
grex 是由 Peter M. Stahl(pemistahl)开发的正则表达式生成工具,它能够根据用户提供的测试用例自动生成匹配的正则表达式。与手动编写正则表达式的繁琐过程不同,grex 接受一组字符串作为输入,然后自动推导出最精确的正则表达式,保证匹配给定的所有测试用例且不遗漏。该工具即可以用作命令行工具,也可以作为 Rust 库集成到其他项目中,同时它还提供了 Python 绑定。grex 的应用场景包括文本提取、数据校验、日志解析、代码生成等,是开发者在日常工作中处理正则表达式难题的高效助手。
前置条件
| 环境/工具 | 描述 |
|---|---|
| 适配库 | grex |
| 开源协议 | "Apache-2.0" |
| 源码版本 | 1.4.6 |
| 目标平台 | 鸿蒙PC |
| 依赖项 | 无 |
| 操作系统平台 | macOS |
| 原仓库地址 | https://github.com/pemistahl/grex |
| 鸿蒙化适配仓库地址 | https://atomgit.com/OpenHarmonyPCDeveloper/ohos-grex |
在Ubuntu中搭建鸿蒙PC 三方库交叉编译构建开发环境 |
https://blog.csdn.net/zl392321162/article/details/159284760 |
在 macOS 中搭建鸿蒙 PC 三方库交叉编译开发环境 |
https://blog.csdn.net/zl392321162/article/details/159284830 |
Windows 10 上安装和使用 WSL 2、安装 Ubuntu 24 详细指南 |
https://blog.csdn.net/yyz_1987/article/details/148545443 |
| 鸿蒙 PC 命令行适配指南(Mac 版) | https://blog.csdn.net/qq_39132095/article/details/154796658 |
| 鸿蒙 PC 生态三方软件移植:开发环境搭建及三方库移植指南 | https://blog.csdn.net/yyz_1987/article/details/154794871 |
OpenHarmony Linux 命令行工具适配实战:基于 Cursor × WSL 的 tree 2.2.1 交叉编译与 HNP 打包全流程指南 |
https://weishuo.blog.csdn.net/article/details/155140843 |
社区维护的鸿蒙 PC 生态命令行工具构建框架 lycium_plusplus |
https://atomgit.com/OpenHarmonyPCDeveloper/lycium_plusplus |
| 支持Rust三方库适配的扩展lycium框架 | https://atomgit.com/CodexBai/lycium_plusplus.git |
| 鸿蒙PC端二进制文件签名命令行使用指南 | https://blog.csdn.net/jianguo888888/article/details/156644386 |
hnp包验证环境 |
https://bxming.blog.csdn.net/article/details/155073889 |
系列索引
| 篇章 | 标题 | 内容 |
|---|---|---|
| 第一篇 | 概述与环境配置 | Lycium 概念、构建机要求、OHOS SDK 配置 |
| 第二篇 | 项目结构与适配目录创建 | 目录结构、community vs thirdparty、创建适配目录 |
| 第三篇 | HPKBUILD 编写详解 | 元数据字段、过程函数、三种构建系统写法 |
| 第四篇 | 构建执行与产物获取 | 构建流程、日志分析、多库递归、HAP 集成 |
| 第五篇 | 流程图与角色职责 | 完整流程图、各角色职责、协作时序 |
| 第六篇 | 关键注意事项与最佳实践 | 依赖管理、架构超集、日志调试、外部适配仓 |
| 第七篇 | 快速参考与模板 | 入门步骤、模板、完整案例、检查清单 |
| 第八篇「番外」 | 扩展lycium框架使其满足rust三方库适配 | 不改变框架原有设计,增加Rust三方库适配能力 |
一、环境配置
1 OpenHarmony SDK 安装
1.1 下载 SDK(环境搭建)
从OpenHarmony 官方首页下载 ohos-sdk 压缩包,步骤省略,详情可见前置条件中环境搭建相关文章。
SDK 下载注意事项:
- 需要注册并登录
AtomGit账户才可以下载。- 使用
Mac系统的开发者一定要下载linux版本的 sdk。- 存放路径不要含有中文字符、空格或特殊字符,建议直接放在用户根目录。
- 资源目录中依赖
ohos-sdk压缩包,解压后请勿移动/删除原始压缩包。
1.2 SDK 放置位置
接下来,我们需要将 ohos-sdk 解压并放置到适当的位置。以下是适用于 Linux 和 macOS 的示例命令:
# Linux / macOS 示例(包名以 DCP 页面为准)
cd ~/
tar -xzf ohos-sdk-linux-v5.0.0-*.tar.gz
mv ohos-sdk ohos-sdk # 统一命名为 ohos-sdk
1.3 SDK 目录结构
解压后 SDK 的目录结构大致如下:
ohos-sdk/
├── linux/ # 主机平台工具链
│ ├── native/ # Native 开发相关工具
│ │ ├── build-tools/ # cmake、ninja 等构建工具
│ │ ├── llvm/ # LLVM 工具链(clang、lld 等)
│ │ ├── sysroot/ # 系统根目录,包含 OHOS 头文件和库
│ │ ├── nativeapi_syscap_config/
│ │ └── ...
│ └── ...
└── ...
1.4 环境变量配置
将 SDK 路径添加到 shell 配置文件(如 ~/.zshrc、~/.bashrc 或 ~/.bash_profile):
# OpenHarmony SDK 路径
export OHOS_SDK_HOME="$HOME/ohos-sdk"
export OHOS_NATIVE_HOME="$OHOS_SDK_HOME/linux/native"
# 添加到 PATH
export PATH="$OHOS_NATIVE_HOME/build-tools/bin:$OHOS_NATIVE_HOME/llvm/bin:$PATH"
# 验证
source ~/.zshrc # 或 source ~/.bashrc
1.5 验证 SDK 配置
使用以下命令验证 OHOS SDK 是否正确配置:
# 检查 SDK 路径
echo $OHOS_SDK_HOME
# 期望输出: /Users/your-username/ohos-sdk
# 检查工具是否在 PATH 中
which cmake
which ninja
# 期望输出: /Users/your-username/ohos-sdk/linux/native/build-tools/bin/cmake
# 期望输出: /Users/your-username/ohos-sdk/linux/native/build-tools/bin/ninja
# 检查 SDK 工具目录
ls $OHOS_NATIVE_HOME
# 期望看到: build-tools llvm sysroot nativeapi_syscap_config 等目录
# 验证工具版本
cmake --version
ninja --version
2 Rust 工具链安装
Rust 工具链的安装方法在所有平台上基本一致,关键在于添加正确的 OHOS 目标平台支持。
2.1 安装 Rust
# 安装 Rust(如果未安装)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# 验证安装
rustc --version # 应显示 rustc 1.xx.x 或更高版本
cargo --version # 应显示 cargo 1.xx.x
2.2 添加 OHOS 目标平台
# 添加 OHOS 的目标平台支持
rustup target add aarch64-unknown-linux-ohos
2.3 配置 Rust 环境变量
# Rust 环境变量(通常由 rustup 自动添加)
export CARGO_HOME="$HOME/.cargo"
export PATH="$CARGO_HOME/bin:$PATH"
export OHOS_RUST_TARGET=aarch64-unknown-linux-ohos
# 验证
source ~/.zshrc
echo $OHOS_RUST_TARGET
# 期望输出: aarch64-unknown-linux-ohos
注意:实际编译时,
lycium会自动设置环境变量,用户一般无需手动设置。
二、适配步骤
1. 分析grex构建特性
grex 由Rust语言编写,使用Cargo作为构建系统,支持作为命令行工具和 Rust 库使用。编译后产出的二进制命令为grex(与包名相同)。grex 的 Cargo.toml 中 default = ["cli"] 表示默认启用 clap 命令行解析功能,可选特性包括 cli(命令行接口)和 python(Python 绑定)。所有依赖均为纯 Rust 实现,无需 C 库链接,交叉编译难度较低。
核心特性
-
自动生成正则表达式
接受一组字符串测试用例作为输入,自动推导出最精确的正则表达式,保证匹配所有给定的输入。算法基于 DFA(确定性有限自动机)和字符类合并,结果精确且不会过度匹配。
-
支持多种正则风格
生成的表达式兼容 Perl 兼容正则表达式(PCRE)以及 Rust 的
regex库语法。通过命令行标志可以控制是否使用简写字符类(\w、\d、\s等),默认生成最精确的模式。 -
转换大小写不敏感模式
支持通过
--case-insensitive标志生成大小写不敏感的正则表达式,自动处理[a-zA-Z]与(?i)前缀等不同实现方式,简化文本匹配场景的表达式编写。 -
转义非 ASCII 字符
支持将非 ASCII 字符转换为 Unicode 转义序列(
\u{...}格式),也可控制是否转换数字和单词边界字符类,让生成的表达式在不同环境下保持兼容。 -
交替替换与捕获组
支持对多组输入字符串分别生成子表达式,然后通过交替符号(
|)组合。对于更复杂的场景,还可以生成带命名捕获组的正则表达式,方便对匹配结果进行分类提取。 -
最小化表达式长度
内置表达式优化引擎,自动简化生成的正则表达式,消除冗余字符类、合并相邻字面量、移除不必要的量词,从而在保证匹配准确性的前提下尽可能缩小表达式长度。
2. 创建适配项目
参考前置条件列表完成lycium_plusplus交叉框架编译环境搭建,以及lycium_plusplus交叉框架代码克隆,在lycium_plusplus/RustAdapt创建目标库grex适配目录为ohos-grex。
为什么是
ohos-grex?为了和源库名称做区分,表示该库用于ohos设备。
ohos-grex创建可以借助编辑器工具(如VSCode)或者使用文件夹在lycium_plusplus/RustAdapt目录下创建目标库适配目录ohos-grex,也可以执行以下命令进行创建。
# 我将交叉编译框架克隆在根目录,此处可改为正确的目录地址
cd ~/lycium_plusplus/RustAdapt
mkdir ohos-grex
3. 编写HPKBUILD
然后将lycium/template/HPKBUILD.cargo拷贝到RustAdapt/ohos-grex目录下,并重命名为HPKBUILD,HPKBUILD是lycium交叉编译框架完成编译构建的核心配置文件,定义包的元信息、依赖、构建和打包逻辑。需要根据模板在HPKBUILD开头声明grex的基本信息,这些字段被lycium用于下载、组织和记录:
# lycium_plusplus/RustAdapt/ohos-grex/HPKBUILD
pkgname=grex # 库名
pkgver=1.4.6 # 库版本
pkgrel=0 # 发布号
pkgdesc="grex generates regular expressions from user-provided test cases." # 库描述
url="https://github.com/pemistahl/grex" # 官网链接
archs=("arm64-v8a") # cpu 架构
license=("Apache-2.0")
depends=() # 依赖库的目录名 必须保证被依赖的库的archs是当前库的archs的超集
makedepends=("cargo" "rustc") # 构建库时的依赖工具->需要用户安装的工具
source="https://github.com/pemistahl/grex/archive/refs/tags/v${pkgver}.tar.gz" # 库源码下载链接
downloadpackage=true # 是否自动下载压缩包,如若不写默认 true. (应对一些特殊情况,代码只能 git clone (项目中依赖 submoudle ))
autounpack=true # 是否自动解压,如若不写默认 true, 如果为 false 则需要用户在 prepare 函数中自行解压
buildtools=cargo # 编译方法: cmake(默认) | configure | cargo | 其它则不在此注入 buildargs,由 build() 自行处理
builddir=grex-${pkgver} # 源码压缩包解压后目录名 编译目录名
packagename=$builddir.tar.gz # 压缩包名
| 字段 | 配置值 | 用途 |
|---|---|---|
pkgname |
grex |
pkgname=grex:包名,用于在 LYCIUM_ROOT/usr/ 下创建安装目录、标识依赖关系。 |
pkgver |
1.4.6 |
pkgver=1.4.6:上游版本号,与 https://github.com/pemistahl/grex 仓库最新发行版本保持一致。 |
pkgrel |
0 |
pkgrel=0:包发布号,当同一上游版本需要重新打包时递增,首次适配为 0。 |
pkgdesc |
- | 包的简短描述,取自 grex 官方 README。 |
url |
- | 上游项目主页 URL。 |
archs |
("arm64-v8a") |
archs=("arm64-v8a"):声明支持的架构数组。此处仅列出 arm64-v8a,但代码内部实际也处理了 armeabi-v7a 和 x86_64,此处是声明"主要支持"而非"仅支持"。当前鸿蒙 PC 设备为 arm64 架构,因此必须配置arm64-v8a。 |
license |
("Apache-2.0") |
grex 采用 Apache-2.0 协议。 |
depends |
() |
无运行时依赖。 |
makedepends |
("cargo" "rustc") |
makedepends=("cargo" "rustc"):编译时依赖。Rust 工具链是构建前提。 |
source |
refs/tags/v${pkgver}.tar.gz |
源码包下载地址。使用 ${pkgver} 变量拼接,下载 grex 1.4.6 的 release tarball(注意标签含 v 前缀)。 |
downloadpackage |
true |
downloadpackage=true:告诉 lycium 构建系统自动下载 source 指定的源码包。如果设置为false需要在目标库目录下手动下载源码包。 |
autounpack |
true |
autounpack=true:下载后自动解压,无需手动解压步骤。如果设置为false需要手动解压。 |
buildtools |
cargo |
buildtools=cargo:声明构建工具类型。lycium 据此选择 Cargo 构建流程(而非 make/cmake 等)。 |
builddir |
grex-${pkgver} |
builddir=grex-${pkgver}:解压后的源码目录名。prepare()/build()/package() 均通过 cd $builddir 进入此目录。 |
packagename |
${builddir}.tar.gz |
packagename=${builddir}.tar.gz:源码包文件名,用于校验/定位。 |
package函数中编译完成后的二进制文件名称与包名一致,grex项目编译完成后,会产出一个名为grex的二进制文件,此处需要将cp target/${OHOS_RUST_TARGET}/release/xxx改为cp target/${OHOS_RUST_TARGET}/release/grex并复制到安装目录。
# 打包安装
package() {
# 进入 Rust 项目目录(和编译时同一个目录)
cd $builddir
# 定义安装路径:鸿蒙库的安装目录
DEST="$LYCIUM_ROOT/usr/$pkgname/$ARCH"
# 创建安装目录bin 文件夹
mkdir -p $DEST/bin/
# 【关键】把编译好的 Rust 程序 → 复制到目标目录的 bin 文件夹
cp target/${OHOS_RUST_TARGET}/release/grex "$DEST/bin/"
cd $OLDPWD
}
4 HNP 打包配置
在lycium_plusplus/RustAdapt/ohos-grex目录下创建hnp.json文件,因为在HPKBUILD中存在archive函数,用于将产物打包为 output/<arch>/<pkgname>_<ver>.tar.gz,或执行 HNP 打包,详细介绍可参考系列索引-构建执行与产物获取。
{
"type": "hnp-config",
"name": "grex",
"version": "1.4.6",
"install": {}
}
5 交叉编译并解决可能存在的问题
HPKBUILD中函数不做改变,在lycium_plusplus/lycium目录下打开终端工具,输入./build.sh ohos-tokei进行第一次交叉编译。

如果提示ALL JOBS DONE!!!表示当前交叉编译没有问题,编译后的产物,可以在lycium/usr/目录和out/arm64-v8目录下查看。

三、 在鸿蒙PC上验证交叉编译后的grex命令是否可用
将lycium_plusplus/lycium/usr/grex/arm64-v8a/bin/grex二进制文件传到鸿蒙PC上,方式有多种,可以通过聊天软件。macos设备可以在App Store下载【鸿蒙星河互联】,通过分享方式将grex二进制文件发送到鸿蒙PC设备上,这种方式需要鸿蒙PC开启华为分享为所有人可见。在鸿蒙PC右下角会弹出接受弹窗,选择"接受"或者"另存为",接受grex二进制文件。接受后的二进制文件是不可以直接运行的,哪怕使用chmod +x grex这种方式授权也是无法运行的。需要给二进制文件进行签名后才可以,在鸿蒙 PC 侧执行前涉及二进制签名流程,可参考《鸿蒙PC端二进制文件签名命令行使用指南》。打开鸿蒙PC终端,输入以下命令为grex签名授权。
# 进入grex所在目录
cd Desktop
# 执行签名
binary-sign-tool sign -inFile grex -outFile grex -selfSign "1"
# 授予权限
chmod +x grex
# 查看grex版本
./grex --version
# 使用 grex 生成匹配 foo、fooo、foooo 的正则表达式
./grex foo fooo foooo
# 使用 grex 生成匹配 foo bar baz 的大小写不敏感正则表达式
./grex --case-insensitive foo bar baz

四、 FAQ
执行签名命令出现“zsh: command not found: binary-sign-tool”提示。
需要在应用市场搜索DevBox并安装,DevBox提供了一些开发者常用命令,主要包含文件和目录操作命令、网络命令、构建命令、签名工具等。

更多推荐

所有评论(0)