#创作者激励# 【FFH】子系统,部件,模块编译构建全实践 原创 精华
【本文正在参加2023年第一期优质创作者激励计划计】
子系统,部件,模块编译构建全实践
个人简介:
深圳技术大学FSR实验室
大三学生,正于九联科技
实习,共同学习研究鸿蒙南向开发
知识。
博客主页:https://ost.51cto.com/person/posts/15624680
Table of Contents
前言
大家好,前段时间学业比较忙,已经有挺长一段时间没有更新博客了,这段时间开始实习生活,会将更多的精力投入到开源鸿蒙的研究学习中,会尽量多更新实习期间的所学所得,分享给大家,一起学习进步!
本篇文章要分享的是OpenHarmony的一个编译构建实践,随着版本更新,OpenHarmony的编译方式也会出现一些小变化,这次将以OpenHarmony-3.2-Beta版本为例,使用九联UnionPi-Tiger开发板,介绍下子系统,部件,模块的配置规则以及编译构建实践。
概述
OpenHarmony整体遵从分层设计,从下向上依次为:内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 部件”逐级展开,在多设备部署场景下,支持根据实际需求裁剪某些非必要的子系统或部件。
-
子系统:子系统是一个逻辑概念,它具体由对应的部件构成。
-
部件:对子系统的进一步拆分,可复用的软件单元,它包含源码、配置文件、资源文件和编译脚本;能独立构建,以二进制方式集成,具备独立验证能力的二进制单元。需要注意的是下文中的芯片解决方案本质是一种特殊的部件。
-
模块:模块就是编译子系统的一个编译目标,部件也可以是编译目标。
-
特性(feature):特性是部件用于体现不同产品之间的差异。
上图编译子系统的各部分关系,主要体现为:
- 子系统是某个路径下所有部件的集合,一个部件只能属于一个子系统。
- 部件是模块的集合,一个模块只能归属于一个部件。
- 通过产品配置文件配置一个产品包含的部件列表,部件不同的产品配置可以复用。
- 部件可以在不同的产品中实现有差异,通过变体或者特性feature实现。
- 模块就是编译子系统的一个编译目标,部件也可以是编译目标。
环境
- OpenHarmony-3.2-Beta5
- 九联UnionPi-Tiger开发板
- USB_Burning_Tool烧录工具
- 串口调试助手
参考
编译构建指导
NAPI框架生成代码集成到OpenHarmony的方法
一. 子系统配置
通过build仓下的subsystem\_config.json
可以查看所有子系统的配置规则。子系统的配置规则主要是在build/subsystem_config.json中指定子系统的路径和子系统名称
。
注意:在已有子系统的目录下再创建子系统会导致重复获取到部件配置文件而导致报错。(血泪教训)
二. 部件配置
bundle.json与ohos.build
配置完子系统后,系统会自动识别该目录下的所有部件配置文件,新增部件的方式有两种,分别为增加ohos.build文件方式和增加bundle.json文件方式,各自的配置方法如下。
1. ohos.build配置格式
2. bundle.json配置格式
- 部件配置中需要配置部件的名称、源码路径、功能简介、是否必选、编译目标、RAM、ROM、编译输出、已适配的内核、可配置的特性和依赖等属性定义。
使用场景对比
两种集成方式使用场景说明:
ohos.build方式集成:适合3.0前版本使用。
bundle.json方式集成:兼容ohos.build方式,但3.1及以后版本建议使用此种方式集成,更好兼容HPM。
三. 模块配置
具体参考模块配置规则。
编译子系统通过模块、部件和产品三层配置来实现编译和打包。模块就是编译子系统的一个目标,包括(动态库、静态库、配置文件、预编译模块等)。模块要定义属于哪个部件,一个模块只能归属于一个部件。OpenHarmony使用定制化的Gn模板来配置模块规则。
以下是常用的模块配置规则:
ohos开头的模板对应的.gni文件路径在:openharmony/build/templates/cxx/cxx.gni。
这里以ohos_executable为例,配置规则如下:
四. 编译构建全实践
1. 添加子系统mysubsys
在子系统下新建一个属于自己的名为mysubsys子系统,并在源码下建立相应的mysubsys目录。
在mysubsys新建两个部件,分别用来测试bundle.json以及ohos.build配置部件的实现结果。注意ohos.build或者bundle.json文件均在对应子系统所在文件夹下,BUILD.gn文件位置可以根据需要指定,整体目录结构如下:
2. 为子系统配置部件及模块
2. 1 添加ohos.build测试部件及模块
mysubsys下新建一个ohos.build文件,根据ohos.build配置规则进行配置。同目录下建立BUILD.gn编译脚本,用于指定部件下模块编译入口,然后新建文件夹test作为测试模块,里面在新建test.c源文件以及BUILD.gn文件,生成可执行文件安装到开发板bin目录下,可执行文件名为mysubsys_test_ohos。编译构建关系如下图所示:
用于测试的源文件test.c:
2.2 添加bundle.json测试部件及模块
mysubsys下新建一个bundle.json文件,根据obundle.json配置规则进行配置。同目录下建立BUILD.gn编译脚本,用于指定部件下模块编译入口,然后新建文件夹test作为测试模块,里面在新建test.c源文件以及BUILD.gn文件,生成可执行文件安装到开发板bin目录下,可执行文件名为mysubsys_test_bundle。编译构建关系如下图所示:
上述两个实例可以直接在"module_list"或者"sub_component"里面直接将编译入口设置为你的模块目标(动态库、静态库、配置文件、预编译模块等),不过在学习过程中,发现OpenHarmony源码里面关于部件模块的写法(例如third_party),发现很多都会额外写一个BUILD.gn来新建一个group,用来包含一个或多个目标的虚节点,这里我也习惯这么写了。
3. 产品配置中添加相应子系统及部件
在vendor/unionman/unionpi_tiger/config.json
文件添加如下配置:
4. 编译烧录运行
操作流程具体参考https://gitee.com/openharmony/device_board_unionman/blob/master/unionpi_tiger/README_zh.md,这里不多赘述。
电脑连接开发板debug口,打开串口工具,生成的可执行文件mysubsys_test_ohos,mysubsys_test_bundle都可以在bin目录找到,在终端执行执行:
结果:
羡慕作者找到鸿蒙实习的机会,期待作者的成长
大佬tql,带带我ORZ
未来模块化肯定是越来越多的