OpenHarmony开发者论坛
标题:
部件独立编译整改规则
[打印本页]
作者:
深开鸿_王石
时间:
6 天前
标题:
部件独立编译整改规则
[md]# 部件独立编译整改规则
## 看板路径
[
https://ci.openharmony.cn/workbe ... uild/componentCheck
](
https://ci.openharmony.cn/workbe ... uild/componentCheck
)
## 1 规则一：InnerAPI模块类型规则
### 1. 禁止InnerAPI模块为source\_set
#### 1.1 问题说明
示例： base\\security\\selinux\\BUILD.gn
引用方：base\\startup\\init\\services\\begetctl\\BUILD.gn
#### 1.2 整改方式
将source\_set目标修改为ohos\_static\_library目标，把源码依赖变更为静态库依赖，静态库作为部件的InnerAPI供其它部件调用。
---
### 2 ：禁止InnerAPI模块为group
#### 2.1 问题说明
third\_party\\f2fs-tools\\BUILD.gn
base\\startup\\init\\services\\BUILD.gn
#### 2.2 整改方式
不允许用group作为InnerAPI，一般group里都是一些目标集合，可以直接依赖集合里的这些目标即可，或将集合中需要对其他部件暴露的目标添加为单独的innerapi子项即可
---
### 3 ：禁止InnerAPI模块为executable
#### 3.1 问题说明
third\_party\\mksh\\BUILD.gn
base\\startup\\init\\services\\init\\standard\\BUILD.gn
#### 3.2 整改方式
这种executable目标其实并不会参与实际的编译过程，而只是表明在运行中需要用到这个二进制，只用在最后镜像打包能够打进去就够了：
1.删除gn中executable目标的deps;
2.确保executable目标在对应部件bundle.json中有描述，比如third\_party/mksh的bundle.json：如果该bundle.json中的sub\_component或者是group已经包含了executable目标，则不用修改bundle.json，这一步只是为了保证在单独编译third\_party/mksh时，能够编译到该executable目标。
3.确保在对应产品****config.json中包含executable目标对应的子系统和部件：
---
### 4：禁止InnerAPI模块为其他任何非lib类型
#### 4.1 问题说明
在前文描述中我们讲到，InnerAPI只允许lib类型，所以除上述描述的source\_set、group、executable等之外，还有可能其他非lib类型作为InnerAPI暴露出去，这个也是不允许的。
#### 4.2 整改方式
根据实际类型来单个看整改方式。
---
## 2 规则二：禁止绝对路径依赖其它部件
### 2.1 问题说明
示例：
base\\startup\\init\\interfaces\\innerkits\\BUILD.gn
### 2.2 整改方式
修改引用方式：deps修改为external\_deps，public\_deps修改为public\_external\_deps，前提是在依赖部件的bundle.json里将对应的目标声明成InnerAPI
示例：
base\\customization\\config\_policy\\bundle.jsonbase\\startup\\init\\interfaces\\innerkits\\BUILD.gn注意: 按照上面规则修改好依赖方和被依赖方的build.gn以及被依赖方的bundle.json后 如果被依赖方是一个三方的innerapi 如 : **//third\_party/ffmpeg:yyyy** 要记得在 依赖方的bundle.json内deps里third\_party内的 **ffmpeg** 移动到components内
---
## 3 规则三：禁止import其它非build框架外的模块的gni
3.1 问题说明
示例： 不规范文件 base\\telephony\\core\_service\\utils\\BUILD.gn
被importde gni "//foundation/communication/wifi/wifi/wifi.gni"
### 3.2 整改方式
1.gni中大多都是feature宏等定义，这些直接在自己gni中定义就好了，不要依赖其他gni。
2.如果gni中有python脚本执行或者是定义了模板，这种后面会统一整改放到build仓，先联系build仓committer添加白名单；
---
## 4 规则四：禁止include\_dirs通过绝对路径引用其它部件InnerAPI头文件或私有头文件
### 4.1 禁止include\_dirs通过绝对路径引用其它部件InnerAPI头文件
#### 4.1.1 问题说明
**示例：**
1.在非public\_configs中声明： foundation/communication/wifi/wifi/frameworks/native:wifi\_p2p\_proxy\_impl
2.在public\_configs中声明：
foundation/arkui/napi:ace\_napi\_static
#### 4.1.2 整改方式
1.在非public\_configs中声明的整改方式：
通过external\_deps来依赖头文件对应的部件模块，去除include\_dirs中的绝对路径依赖：
2.在public\_configs中声明的整改方式：
如果include\_dirs所在的config是作为对应模块的public\_config，那么使用public\_external\_deps来依赖对应的部件，并去除include\_dirs中的绝对路径依赖：
### 4.2 禁止include\_dirs通过绝对路径引用其它部件的私有头文件
#### 4.2.1 问题说明
示例：
base/telephony/sms\_mms/BUILD.gn而//third\_party/glib对应的部件模块InnerAPIs并未开放此目录下的头文件。
#### 4.2.2 整改方式
1、先自排查是否是冗余；
2、如果外部确实用到了这些头文件，那么这些头文件应该要放到其InnerAPI中：
比如上述的两个头文件，则需将该头文件在其InnerAPI中使用public\_config暴露出来，然后sms\_mms的BUILD.gn中使用external\_deps来依赖此InnerAPI。
---
## 5 规则五：禁止InnerAPI对外头文件路径过大
### 5.1 问题说明
直接对外开放整个仓路径。
示例：
third\_party\\cJSON\\BUILD.gn
### 5.2 整改方式
**尽可能缩小范围，只开放InnerAPI相关头文件。**
---
## 6 规则六：禁止使用all\_dependent\_configs
### 6.1 问题说明
foundation\\distributeddatamgr\\preferences\\interfaces\\inner\_api\\BUILD.gnall\_dependent\_configs中列出的config会被强制应用到当前target，以及依赖当前target的target中，也会传递下去：
比如target A中设置了这个值，而B依赖A，C依赖B，D依赖C，那么B、C、D中都会被应用这个变量所指定的config**。**
### 6.2 整改方式
1.先确认是否可以修改为configs；
2.如果确实需要对外开放，那么改为public\_configs，缺失的依赖用external\_deps引入public\_configs所在部件模块。
---
## 7 规则七：禁止InnerAPI中使用public\_deps依赖部件内模块
### 7.1 问题说明
foundation\\graphic\\graphic\_2d\\utils\\gl\_utils\\BUILD.gn
如果InnerAPI中使用了public\_deps中依赖了部件内模块，那么在部件化编译下载依赖二进制包的时候无法识别到public\_deps对应的二进制包。
### 7.2 整改方式
部件内使用deps依赖，如果确实需要将部件内模块传递出去，那么将该模块需要传递的内容放到InnerAPI中。
---
## 8 规则八：禁止在代码中使用../路径引入其他部件的头文件
### 8.1 问题说明
A部件的a.cpp文件，引用了a.h和b.h，其中a.h和b.h是其他部件（B）的InnerAPI头文件：
**复制代码**
```
#include "../b.h"
#include "../../a.h"
```
其中B中对应InnerAPI对外头文件声明的路径如下：
include\_dirs = [ "includes", "includes/b", "includes/b/c" ]，有自包含关系
所以如果基于"includes/b/c"这个目录，#include "../b.h"和#include "../../a.h"的写法是可以引用到具体的头文件的，但是部件独立编译生成二进制依赖后，include_dirs的路径统一规范化为include_dirs = [ "includes" ]，所以再用上述这种../的引用是有问题的。
### 8.2 整改方式
像上述这种InnerAPI对外的include\_dirs中目录有包含关系的，使用方统一将最顶层的路径作为根路径引用，即include\_dirs = [ "includes", "includes/b", "includes/b/c" ]里的三个路径以"includes"为根路径：
**复制代码**
```
#include "b/b.h"
#include "a.h"
```
---
## 9 规则九：InnerAPI必须在bundle.json中描述
### 9.1 问题说明
本部件模块如果被其他部件依赖，那么检查该模块在本部件bundle.json的inner\_kits字段中是否有描述，如果没有则要加上去：
A部件依赖init部件的的libbegetutil：
**复制代码**
```
external_deps = [
"init":"libbegetutil",
]
```
### 9.2 整改方式
在init部件的bundle.json中innerkit中则要添加libbegetutil：
---
## 10 规则十：InnerAPI如果定向开放，则必须在bundle.json中用visibility描述
### 10.1 问题说明
有一些InnerAPI可能只是针对某些部件开放，所以在bundle.json中新增可选字段visibility，来描述这个innerkit只针对哪些部件开放（可写多个），如果没有这个字段，则默认全局开放。
## 小结
1 规则一：InnerAPI模块类型规则
2 规则二：禁止绝对路径依赖其它部件
3 规则三：禁止import其它非build框架外的模块的gni
4 规则四：禁止include\_dirs通过绝对路径引用其它部件InnerAPI头文件或私有头文件
5 规则五：禁止InnerAPI对外头文件路径过大
6 规则六：禁止使用all\_dependent\_configs
7 规则七：禁止InnerAPI中使用public\_deps依赖部件内模块
8 规则八：禁止在代码中使用../路径引入其他部件的头文件
9 规则九：InnerAPI必须在bundle.json中描述
10 规则十：InnerAPI如果定向开放，则必须在bundle.json中用visibility描述
---
[/md]
欢迎光临 OpenHarmony开发者论坛 (https://forums.openharmony.cn/)
Powered by Discuz! X3.5