部件独立编译整改规则
看板路径
https://ci.openharmony.cn/workbench/cicd/dailybuild/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.json
base\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.gn
all_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描述
发布问题
发布文章
