鸿蒙OpenHarmony【部件编译构建规范】子系统

前言

目的

编译构建是部件化设计落地的切入点,一个优秀的部件在编译态应该具备可维护、可移植、低耦合的特征。本规范用于引导部件开发人员编写符合部件化设计的编译脚本,使得部件在编译态依赖合理、可配置、可复用、可裁剪。

基本概念

部件

部件是OpenHarmony系统能力的基本单元,以源码为划分依据,具有独立的仓和目录,在不同的设备上可实例化为不同的库或二进制文件。

特性

部件特性为编译态可配置的编译选项,可供产品在编译时按需配置。不同的特性配置,编译出部件的不同形态,使得部件可以适应不同形态产品的差异化需求。部件特性的配置只影响部件内部功能的实现差异,不能影响部件的Public API(部件对应用提供的接口)以及inner api(部件间的接口)。

依赖

在编译态,部件的依赖分为:

  • 有条件依赖:在特定场景下可裁剪的依赖,有条件的依赖裁剪后不影响部件的Public API 和inner api。比如音频对蓝牙的依赖。
  • 强依赖:部件间合理的必要的依赖,不可裁剪。比如syscap部件对安全库函数的依赖。

总体原则

部件编译构建应遵循以下几个原则:

独立自治

部件编译态应内聚,新增外部依赖时应慎重,尽量减少编译时的静态依赖。

合理依赖

部件间的依赖都应基于部件间的接口,禁止依赖其他部件内部的模块和头文件。

产品无关

部件在编译态应是多产品通用的,禁止在编译脚本中使用产品名称。

约定

规则:  必须遵守的约定。

建议:  必须加以考虑的约定。

看护手段

为了维护部件编译构建规范,门禁会对构建配置文件做一些检查。

预编译检查:指在预编译阶段进行检查,检测到错误将报错并停止编译。

静态检查:指检查工具对配置文件进行扫描检查,非编译手段。

例外

在不违背总体原则,经过充分考虑,有充足的理由的前提下,可以适当违背规范中约定。

例外破坏了代码的一致性,请尽量避免。“规则”的例外应该是极少的。

命名

编译脚本中的变量、编译目标(target)、模板,gni文件,以及部件描述文件中的对象和数据的命名都应采用内核风格(unix_like),单词全小写,用下划线分割。如:“startup_init”。

规则1.1 部件名格式须统一

  • 名词形式,需体现部件的功能。
  • 在系统内全局唯一。
  • 不超过63个有效英文字符。
<think>好的,我现在要帮助用户了解如何学习OpenHarmony源码以及进行编译构建。首先,我需要整理用户提供的引用内容,看看里面有没有相关的指导信息。用户给出了四个引用,都是关于OpenHarmony编译过程和构建工具的。引用1提到编译过程分析完毕,并推荐另一篇关于编译构建的文章。引用2介绍了OpenHarmony的背景和学习阶段,分为看、实操、写。引用3提到DevEco Studio和Hvigor构建工具。引用4详细解释了构建工具链,包括GN、Ninja、clang/llvm等。 接下来,我需要根据这些信息构建一个结构清晰的回答。用户的需求是学习源码和编译构建的教程,所以需要分步骤来指导。可能需要包括环境准备、源码获取、工具链理解、编译配置、实操步骤、问题排查等部分。同时,用户要求生成相关问题,所以还要考虑可能的相关问题。 首先,回答的结构应该按照学习步骤来组织,比如从环境准备开始,然后获取源码,再了解工具链,接着配置编译,最后实操。每个步骤中需要引用提供的资料中的内容,比如引用4提到的GN、Ninja等工具,需要解释清楚它们的作用。引用2提到的学习阶段可以作为框架,引导用户从理论到实践再到总结。 同时,需要确保使用正确的中文表达,行内公式用$...$,独立公式用$$...$$,但当前问题可能不涉及数学公式,所以可能不需要使用。但需要检查是否有需要用到的地方,比如构建过程中的某些参数或命令是否需要特别标注。 然后,生成相关问题需要考虑用户可能进一步想知道的内容,比如编译优化方法、构建失败处理、与其他系统的对比等。根据引用中的内容,比如引用4提到后续会出编译和链接的问题解决,所以相关问题可以涉及常见问题处理。 最后,确保所有引用标识正确添加,比如在提到编译工具链时引用[^4],在环境准备时引用[^3]提到的DevEco Studio。需要自然地在段落末尾添加引用标识,避免打断阅读。 现在需要整合这些思考,按照用户提供的结构来组织回答,确保每个步骤清晰,引用正确,并且生成的相关问题有针对性。</think>### OpenHarmony源码学习与编译构建教程 #### 一、学习准备阶段 1. **环境搭建** - 操作系统:建议使用Ubuntu 18.04及以上版本(官方推荐)。 - 工具链安装:需安装`gn`、`ninja`、`clang/llvm`等核心工具,可通过OpenHarmony官方文档获取安装脚本[^4]。 - 开发工具:推荐使用DevEco Studio作为IDE,支持Hvigor构建插件,用于任务编排和HAP/APP包生成。 2. **源码获取** - 通过官方仓库或镜像站点下载源码,建议使用`repo`工具管理多仓库代码: ```bash repo init -u https://gitee.com/openharmony/manifest.git -b master repo sync -c ``` #### 二、理解编译构建框架 1. **工具链组成** - **GN**:生成`ninja`构建文件,语法简洁,支持模块化配置[^4]。 - **Ninja**:专注于编译速度,通过`gn`生成的`.ninja`文件驱动编译流程。 - **Clang/LLVM**:负责代码编译与优化,支持多平台交叉编译。 2. **构建流程解析** - **配置阶段**:通过`hb set`命令选择目标设备(如Hi3516开发板)。 - **编译阶段**:执行`hb build`触发GN生成构建文件,并由Ninja调用Clang完成编译链接。 - **输出结果**:生成HAP/APP包,位于`out/[device]/[project]/`目录下。 #### 三、实操步骤 1. **首次编译示例** ```bash # 初始化配置 hb set # 选择目标平台(如@ohos_hi3516dv300) hb build -f # 全量编译 ``` 2. **模块化编译** - 若仅需编译特定组件(如`kernel`),可通过以下命令实现: ```bash hb build kernel ``` #### 四、常见问题与优化 1. **依赖缺失** - 若编译报错提示工具缺失,需检查Python版本(要求3.7+)及`gn/ninja`路径配置。 2. **加速编译** - 启用并行编译:`ninja -j [线程数]`,利用多核CPU提升速度[^4]。 - 增量编译:仅修改代码后重新运行`hb build`,避免全量编译。 #### 五、深入学习建议 - **源码结构分析**:重点关注`build/lite`目录,包含编译配置与脚本[^2]。 - **构建扩展**:自定义`BUILD.gn`文件实现新模块添加,参考官方文档中的GN语法指南[^4]。 - **调试技巧**:通过`ninja -v`输出详细编译日志,定位失败原因。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值