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

前言

目的

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

基本概念

部件

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

特性

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

依赖

在编译态，部件的依赖分为：

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

总体原则

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

独立自治

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

合理依赖

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

产品无关

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

约定

规则：  必须遵守的约定。

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

看护手段

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

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

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

例外

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

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

命名

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