鸿蒙OpenHarmony：【关于deps、external_deps的使用】

 关于deps、external_deps的使用

在添加一个模块的时候，需要在BUILD.gn中声明它的依赖，为了便于后续处置惩罚部件间依赖关系，我们将依赖分为两种——部件内依赖deps和部件间依赖external_deps。
依赖分类

开发前请熟悉鸿蒙开发引导文档：gitee.com/li-shizhen-skin/harmony-os/blob/master/README.md点击或者复制转到。
如上图所示，主要分为部件内依赖（图左）和部件间依赖（图右）。

• 部件内依赖： 现有模块module1属于部件part1，要添加一个属于部件part1的模块module2，module2依赖于module1，这种情况就属于部件内依赖。
  
• 部件间依赖： 现有模块module1属于部件part1，要添加一个模块module2，module2依赖于module1，module2属于部件part2。模块module2与模块module1分属于两个不同的部件，这种情况就属于部件间依赖。
  
• 部件内依赖示例：
  
  1. import("//build/ohos.gni")
  2. ohos_shared_library("module1") {
  3.   ……
  4.   part_name = "part1"   # 必选，所属部件名称
  5.   ……
  6. }
  7. import("//build/ohos.gni")
  8. ohos_shared_library("module2") {
  9.   ……
  10.   deps = [
  11.     "module1的gn target",
  12.   ……
  13. ]                        # 部件内模块依赖
  14. part_name = "part1"       # 必选，所属部件名称
  15. }

  复制代码
  
  
• 部件间依赖示例：
  
  1. import("//build/ohos.gni")
  2. ohos_shared_library("module1") {
  3.   ……
  4.   part_name = "part1"   # 必选，所属部件名称
  5.   ……
  6. }
  7. import("//build/ohos.gni")
  8. ohos_shared_library("module2") {
  9.   ……
  10.   external_deps = [
  11.     "part1:module1",
  12.   ……
  13.   ]                      # 部件间模块依赖，这里依赖的模块必须是依赖的部件声明在inner_kits中的模块
  14.   part_name = "part2"    # 必选，所属部件名称
  15. }

  复制代码
  
  
  
  
  留意：部件间依赖要写在external_deps里面，格式为”部件名:模块名"的形式，并且依赖的模块必须是依赖的部件声明在inner_kits中的模块。
  

Sanitizer使用说明

在添加模块时，可选地对该模块开启编译器提供的Sanitizer功能，包罗整数溢出排错、控制流完整性查抄等。配置的每一项都是可选的，如不指定默认为false或者空。Sanitizer配置示例如下所示：

1. ohos_shared_library("example") {
2.     sanitize = {
3.       cfi = true                             # 开启控制流完整性检测
4.       cfi_cross_dso = true                   # 开启跨so调用的控制流完整性检测
5.       integer_overflow = true                # 开启整数溢出检测
6.       boundary_sanitize = true               # 开启边界检测
7.       ubsan = true                           # 开启部分ubsan选项
8.       all_ubsan = true                       # 开启全量ubsan选项
9.       debug = true                           # 可选，调测模式，默认是不开启
10.       blocklist = "./blocklist.txt"          # 可选，屏蔽名单路径
11.     }
12.     ...
13.   }

复制代码

支持的Sanitizer类型
现在支持开启的Sanitizer：

• 整数溢出排错：unsigned_integer_overflow/signed_integer_overflow/integer_overflow(同时包罗无符号和有符号整数溢出两种查抄)
  
• 控制流完整性：cfi、cfi_cross_dso（跨so的cfi查抄）
  
• 边界检测：boundary_sanitize
  
• 部分未定义活动检测：ubsan(bool,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound等编译选项)
  
• 全量未定义活动检测：all_ubsan(全量undefined behavior sanitizer编译选项)
  

发布、调测模式
通过debug选项控制使用发布模式还是调测模式，默认为发布模式，使用debug = true显式声明开启调测模式。debug选项仅对Sanitizer见效，且与模块是否编译为调试版本无关，但在模块发布版本的编译配置中不应带此选项，或显式地将debug设置为false，使得Sanitizer处于发布模式。

• 调测模式：用于开发时排盘问题。该模式下会输出产生错误相干的丰富信息来辅助定位错误，并且在发生错误后并不会直接中断程序运行，而是会恢复程序运行进一步识别后续的错误。
  
• 发布模式：保护程序不发生错误或被恶意攻击，在产生错误后直接中断程序不会继承执行。
  

屏蔽名单
指定该模块中不受Sanitizer选项影响的函数或源程序文件名单，用于避免良性活动被识别为错误、热点函数产生了不合理、不可接受的开销；该名单需谨慎使用。名单示例如下所示：

1. [cfi]
2. fun:*([Tt]est|TEST)*
3. fun: main
5. [integer]
6. src:example/*.cpp

复制代码

开源软件Notice收集策略说明

开源软件Notice是与项目开源相干的文件，收集这些文件的目标是为了符合开源的规范。
收集目标
只收集打包到镜像里面的模块对应的License；不打包的都不收集，比如构建过程使用的工具（如clang、python、ninja等）都是不收集的。
静态库本身是不会被打包的，一样平常是作为动态库或者可执行程序的一部分被打包到体系中的，为了确保完备，静态库的都会收集。
终极合并的NOTICE.txt要体现出镜像中每个文件都是用了哪些License，模块和License要有对应关系。
终极合并的NOTICE.txt文件在/system/etc/ 目录下。
收集规则
按照优先级收集License，以下由1到4，优先级依次低落。

• 模块在BUILD.gn中直接声明本身使用的License文件，优先级最高。如下示例：
  
  1. ohos_shared_library("example") {
  2.     ...
  3.     license_file = "path-to-license-file"
  4.     ...
  5. }

  复制代码
  
  
• 假如模块没有显式声明，那么编译脚本会在BUILD.gn所在的当前目录中查找Readme.OpenSource文件，解析该文件，找出该文件中声明的license，将其作为模块的License。 假如Readme.OpenSource文件中配置的license文件不存在，直接报错。
  
• 假如Readme.OpenSource文件不存在，编译脚本会从当前目录开始，向上层目录探求（一直找到源码的根目录），默认查找License、Copyright、Notice三个文件，假如找到，则将其作为模块的License。
  
• 假如上面三种方式都未找到license，则使用默认的license作为该模块的license；默认license是Apache2.0 License。
  

需要留意及查抄的问题

• 三方的开源软件，比如openssl，icu等，这部分软件基本上在源码目录下都要求配置Readme.OpenSource，要查抄Readme.OpenSource文件是否和BUILD.gn文件在同一个目录，以及Readme.OpenSource文件中配置的License文件是否存在以及真实有效。
  
• 代码目录下，假如代码使用的不是Apache2.0 License，需要在目录下提供对应的License文件，或者直接在模块中指定license_file。
  
• 假如BUILD.gn中添加的源码文件不是当前目录的，需要查抄下源码文件所在仓下的license是否和BUILD.gn文件所在仓的一致。
  

加速本地编译的一些参数

编译时，得当选择添加以下的编译参数可以加速编译的过程。

• 添加--ccache参数:
  
  
  
  • 原理：ccache会缓存c/c++编译的编译输出，下一次在编译输入不变的情况下，直接复用缓存的产物。
    
  • 安装：
    
    
    
    • 快速安装：执行sudo apt-get install ccache下令。
      
    • 官网下载，下载二进制文件，把ccache所在路径配置到情况变量。
      
    
    
  • 使用：执行./build.sh --product-name 产品名 --ccache下令。
    
  
  
• 添加--fast-rebuild参数
  
  
  
  • 原理：编译流程主要分为：preloader->loader->gn->ninja这四个过程，在本地没有修改gn和产品配置相干文件的前提下，添加--fast-rebuild会让你直接从ninja编译开始。
    
  • 使用：执行./build.sh --product-name 产品名 --fast-rebuild下令。
    
  
  
• 添加enable_notice_collection=false参数
  
  
  
  • 原理：省略掉收集开源软件模块的license的过程。
    
  • 使用：执行./build.sh --product-name 产品名 --gn-args --enable_notice_collection=false --ccache下令。
    
  
  
• 添加--build-target参数
  
  
  
  • 该参数用于指定编译模块，怎样找模块的名字：
    
    
    
    • 相干仓下BUILD.gn中关注group、ohos_shared_library、ohos_executable等关键字。
      
    • ./build.sh --product-name 产品名 --build-target 模块名 --build-only-gn天生build.ninja，然后去该文件中查找相干模块名。
      
    
    
  • 使用：执行./build.sh --product-name 产品名 --build-target ark_js_host_linux_tools_packages下令。
    
  
  

检察NinjaTrace

out/rk3568/.ninja_log文件记录了每个模块编译的开始和结束时间(ms)，结束时间和开始时间间隔越短表示模块的编译时间越短，编译性能越高。
从左到右分别表示：start time|end time|mtime|command hash。

图形化显示编译时间。

• 本地打开ninja trace： 解压out/rk3568/build.trace.gz，将build.trace拖到chrome的trace链接chrome://tracing/打开即可。
  
• 在CI网站ci.openharmony.cn/events上打开ninja trace： CI上每个编译的输出里面有build.trace.html可直接打开，具体方法是：
  
  
  
  • 点击静态查抄下的“成功”；
    
  • 点击输出列的“输出”即可在左侧的build_trace列看到build.trace.html文件，单击该文件即可打开。
    
  
  

定制打包chip_prod镜像使用说明

背景

针对同一个芯片解决方案下的子产品的定制能力，将差异能力放到 chip_prod 分区，因此需要支持对不同子产品天生对应的 chip_prod.img。
使用步调

• 产品解决方案配置：
  产品解决方案配置文件config.json中添加"chipprod_config_path"配置选项，即"chipprod_config_path":"子产品定义文件所在的路径"。 此中子产品定义文件的文件名为chip_product_list.gni，文件格式为：chip_product_list = ["productA", "productB", ...] 。
  示例：
  以MyProduct产品定制chipprod镜像为例，//vendor/产品厂商/MyProduct/config.json配置如下：
  
  1. {
  2.      "product_name": "MyProduct",                                 # 产品名称
  3.      "version": "3.0",                                            # config.json的版本号, 固定"3.0"
  4.      "chipprod_config_path": "",                                  # 存放chipprod配置文件路径，可选项
  5. "subsystems": [
  6.        {
  7.          "subsystem": "arkui",                                    # 选择的子系统
  8.          "components": [
  9.            {
  10.                "component": "ace_engine",
  11.                "features":[ "ace_engine_feature_enable_web = true",
  12.                  "ace_engine_feature_enable_accessibility = true" ] }   
  13.          ]
  14.        },
  15.        {
  16.         ......
  17.        }
  18.       ......
  19.       更多子系统和部件
  20.      }
  21. }

  复制代码
  
  
• 模块编译配置：
  某个配置文件在不同的子产品中有差异，比如要打包到productA对应的chip_prod.img中，则模块编译需要配置install_images和module_install_dir。
  以ohos_prebuilt_executable示例：
  
  1. ohos_prebuilt_executable("moduleXXX"){
  2. install_images = [ "chip_prod" ]
  3. module_install_dir = "productA/etc/***"     # module_install_dir指定的路径需要以productA开始。
  4. }

  复制代码
  
  

3.编译下令

1. ./build.sh --product-name {product_name} --build-target chip_prod_image

复制代码

• 打包结果:
  假如定义了子产品productA和productB，即chip_product_list = ["productA", "productB"],并且有模块安装到了该产品下，则打包后镜像输出路径如下：
  
  1. images/productA/chip_prod.img
  2. images/productB/chip_prod.img

  复制代码

鸿蒙Next核心技术分享

1、鸿蒙基础知识←《鸿蒙NEXT星河版开发学习文档》

2、鸿蒙ArkUI←《鸿蒙NEXT星河版开发学习文档》

3、鸿蒙进阶技术←《鸿蒙NEXT星河版开发学习文档》

 4、鸿蒙就业高级技能←《鸿蒙NEXT星河版开发学习文档》 

 5、鸿蒙多媒体技术←《鸿蒙NEXT星河版开发学习文档》 

6、鸿蒙南向驱动开发←《鸿蒙NEXT星河版开发学习文档》  

7、鸿蒙南向内核设备开发←《鸿蒙NEXT星河版开发学习文档》  

 8、鸿蒙体系裁剪与移植←《鸿蒙NEXT星河版开发学习文档》  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。