前言
目的
编译构建是部件化设计落地的切入点,一个优秀的部件在编译态应该具备可维护、可移植、低耦合的特征。本规范用于引导部件开发人员编写符合部件化设计的编译脚本,使得部件在编译态依赖合理、可配置、可复用、可裁剪。
基本概念
部件
部件是OpenHarmony系统能力的基本单元,以源码为划分依据,具有独立的仓和目录,在不同的设备上可实例化为不同的库或二进制文件。
特性
部件特性为编译态可配置的编译选项,可供产品在编译时按需配置。不同的特性配置,编译出部件的不同形态,使得部件可以适应不同形态产品的差异化需求。部件特性的配置只影响部件内部功能的实现差异,不能影响部件的Public API(部件对应用提供的接口)以及inner api(部件间的接口)。
依赖
在编译态,部件的依赖分为:
- 有条件依赖:在特定场景下可裁剪的依赖,有条件的依赖裁剪后不影响部件的Public API 和inner api。比如音频对蓝牙的依赖。
- 强依赖:部件间合理的必要的依赖,不可裁剪。比如syscap部件对安全库函数的依赖。
总体原则
部件编译构建应遵循以下几个原则:
独立自治
部件编译态应内聚,新增外部依赖时应慎重,尽量减少编译时的静态依赖。
合理依赖
部件间的依赖都应基于部件间的接口,禁止依赖其他部件内部的模块和头文件。
产品无关
部件在编译态应是多产品通用的,禁止在编译脚本中使用产品名称。
约定
规则: 必须遵守的约定。
建议: 必须加以考虑的约定。
看护手段
为了维护部件编译构建规范,门禁会对构建配置文件做一些检查。
预编译检查:指在预编译阶段进行检查,检测到错误将报错并停止编译。
静态检查:指检查工具对配置文件进行扫描检查,非编译手段。
例外
在不违背总体原则,经过充分考虑,有充足的理由的前提下,可以适当违背规范中约定。
例外破坏了代码的一致性,请尽量避免。“规则”的例外应该是极少的。
命名
编译脚本中的变量、编译目标(target)、模板,gni文件,以及部件描述文件中的对象和数据的命名都应采用内核风格(unix_like),单词全小写,用下划线分割。如:“startup_init”。
规则1.1 部件名格式须统一
- 名词形式,需体现部件的功能。
- 在系统内全局唯一。
- 不超过63个有效英文字符。