本文正在参加星光计划3.0--夏日挑战赛
一、前言
本篇文章将详细阐述产品信息配置，对config.json中的信息进行介绍，根据产品信息配置和构建配置梳理出组件和模块依赖关系，增加大家对设备开发时的产品构建的了解。
二、产品信息配置
这里以hispark_pegasus产品为例进行介绍，下图为hispark_pegasus产品解决方案目录结构。
<br>
上节已经初步介绍过BUILD.gn和config.json。
接下来我们一起看看config.json文件，仍以hispark_pegasus产品为例，配置文件如下：
{
"product_name": "wifiiot_hispark_pegasus", #产品名称
"type": "mini", #系统类型，可选【mini，small，standard】
"version": "3.0", #config.json的版本号，固定"3.0"
"ohos_version": "OpenHarmony 1.0", #选择的OS版本
"device_company": "hisilicon", #芯片厂商
"board": "hispark_pegasus", #开发板名称
"kernel_type": "liteos_m", #选择的内核类型
"kernel_is_prebuilt": true, #内核是否预编译
"kernel_version": "", #选择的内核版本
"subsystems": [ #选择的子系统
{
"subsystem": "applications",
"components": [
{ "component": "wifi_iot_sample_app", "features":[] }
]
},
{
......
#更多子系统和组件
}
],
"third_party_dir": "//device/soc/hisilicon/hi3861v100/sdk_liteos/third_party",
"product_adapter_dir": "//vendor/hisilicon/hispark_pegasus/hals"
}
为了防止过多的注释，影响了文件本身的数据载体，根据JSON规范(http://www.json.org, RFC 4627, RFC 7159)，json不支持注释,此处注释为本人为了在截取代码旁更直观地进行解释而添加上去的，是无法编译通过的
<br>
- config.json为编译构建的入口，上述代码约定了产品名称、芯片厂商名称、开发板名称、内核类型、内核版本号、子系统、适配路径等信息。
- 上篇文章介绍芯片解决方案的时候提过，一个开发板支持多个内核配置，可以支持相同内核的不同版本，也可以支持配置不同内核。修改内核类型kernel_type和内核版本kernel_version即可切换开发板已适配的内核。
- 产品可以通过修改芯片厂商名称、开发版本名称更换厂商和开发版本，以选择芯片解决方案。
- 除了芯片相关的配置外，config.json中还配置了组件信息。其逐一定义了需要的子系统subsystem。对于每个subsystem，又逐一定义了其包含的components，以及对于每个component所附带的编译features。即配置了产品依赖的系统能力，通过子系统、组件、目标等信息设置具体的依赖对象。通过此功能，OpenHarmony支持根据实际需求裁剪某些非必要的子系统或功能/模块,可通过子系统“组合”出系统功能，增加或删除某些子系统或组件。
-
当我们构建产品的时候，构建工具hb会根据芯片方案的命名规则和config.json中配置的内核类型及内核版本信息查找到开发板内核配置信息。
<br>
那么产品信息配置和芯片解决方案的关系又是什么样的呢？
三、产品信息配置与芯片解决方案的关系
根据源码路径的规则，产品配置信息在vendor目录下，芯片解决方案在device目录下。
- 首先，按照命名规则，并结合config.json中配置的device_company和board信息,编译工具可以找到hispark_pegasusk产品配置的开发板路径。修改这些信息，可以切换不同的芯片解决方案。例如通过config.json中的hisilicon+hispark_pegasus即可知道芯片解决方案位置//device/hisilicon/hispark_pegasus
-
其次，在芯片解决方案目录下，BUILD.gn配置了SDK开发板编译信息。子目录分别保存了SDK相关的其他组件信息。开发板支持的每一个内核版本需要有一个独立的目录来存放，建议的命名方式是“_”连接了kernel_type和kernel_version形成文件夹名称。并且目录中config.gni文件配置开发板相关的编译配置。config.gni中的kernel_type和kernel_version和产品构建配置文件config.json中的配置匹配时，config.gni中的配置将被选为产品对应的板级配置。例如，通过config.json中的liteos_m即可选择//device/hisilicon/hispark_pegasus/liteos_m/config.gni
一般情况下可找到对应的kernel_type_kernel_version/config.gni
综上所述，以图形的方式把hispark_pegasus产品配置展开后，我们可以直观的看到组件间的依赖关系：
BUILD.gn配置了产品解决方案的相关配置，包括依赖的模块等等，但在hispark_pegasus产品代码中仅设置了一个空的构建对象group：
# Copyright (C) 2020 Hisilicon (Shanghai) Technologies Co., Ltd. All rights reserved.
group("hispark_pegasus") {
}
而不空的构建对象如下图hispark_taurus的BUILD.gn
为举例说明，关系图中通过虚线增加了一个init_configs依赖，这样被依赖的模块会一起参与编译。另外，config.json
中配置的芯片和系统组件都会通过我前面所说的一样加入到构建中来（关系图中的红字1,2步骤）
四、引入芯片解决方案的两种方式
hispark把芯片SDK配置到了vendor子系统中，config.json通过子系统和组件配置形成对芯片SDK的依赖，最终一起编译出产品构建。
从流程上来说，产品构建时，首先加载产品构建信息，从config.json中解析出子系统和组件、芯片相关的信息，并识别模块的依赖关系。然后，从产品的编译入口BUILD.gn
开始执行编译，使用gn产生ninja文件，并使用ninja进行编译构建。这是引入芯片解决方案的方式之一——默认编译，隐性依赖。
这种方式不需要在config.json中配置对芯片SDK的依赖
<br>方式二是指通过子系统配置显性依赖
- 在芯片组件目录下，根据模块划分配置各组件构建信息。
- 一般在vendor子系统中配置SDK组件信息，例如:hi3861_sdk。可以配置多个可拆分组合的组件。
- config.json中配置对vendor子系统中SDK的依赖，例如如下摘自vendor/hisilicon/hispark_pegasus/config.json的代码所做的操作：
{
"subsystem": "vendor",
"components": [
{ "component": "hi3861_sdk", "target": "//device/soc/hisilicon/hi3861v100/sdk_liteos:wifiiot_sdk", "features":[] }
]
},
在上述代码指向的target中即可看到对应的芯片解决方案
这种方案需要在vendor子系统中配置芯片SDK组件，然后在config.json中增加对vendor子系统的SDK组件依赖。
这种显性依赖可以明显看出产品解决方案依赖的具体子系统和具体组件。如果SDK提供的组件较多（如上图），可以在vendor子系统中配置多个独立的组件，以便拆分组合不同的系统能力
五、后记
参考文献及教程
OpenHarmony设备开发文档
OpenHarmony基础
本篇文章结合上节提到的产品信息配置和芯片解决方案，梳理分析了前者的具体配置信息以及两者的关系。没有看过上篇文章的可以将其与本篇内容结合起来查看以加深理解。
作为小白，本篇文章可能有不对的地方，欢迎交流探讨~