OpenHarmony子系统开发 -- 构建系统编码规范与最佳实践

news2025/3/11 15:58:53

OpenHarmony子系统开发 -- 构建系统编码规范与最佳实践

概述

gn是generate ninja的缩写，它是一个元编译系统（meta-build system）,是ninja的前端，gn和ninja结合起来，完成OpenHarmony操作系统的编译任务。

gn简介

  • 目前采用gn的大型软件系统有：Chromium，Fuchsia和OpenHarmony。
  • gn语法自设计之初就自带局限性，比如不能求list的长度，不支持通配符等。这些局限性源于其 有所为有所不为 的设计哲学。 所以在使用gn的过程中，如果发现某件事情用gn实现起来很复杂，请先停下来思考这件事情是否真的需要做。
  • 关于gn的更多详情见gn官方文档。

本文的目标读者和覆盖范围

目标读者为OpenHarmony的开发者。本文主要讨论gn的编码风格和使用gn过程中容易出现的问题，不讨论gn的语法，如需了解gn基础知识，见gn reference文档。

总体原则

在保证功能可用的前提下，脚本需要满足易于阅读，便于维护，良好的扩展性和性能等要求。

代码风格

命名

总体上遵循Linux kernel的命名风格，即小写字母+下划线的命名风格。

局部变量

我们这里对局部变量的定义为：在某作用域内，且不向下传递的变量。

为了更好的区别于全局变量，局部变量统一采用下划线开头。

# 例1
action("some_action") {
  ...
  # _output是个局部变量，所以使用下划线开头
  _output = "${target_out_dir}/${target_name}.out"
  outputs = [ _output ]
  args = [
    ...
      "--output",
      rebase_path(_output, root_build_dir),
      ...
  ]
  ...
}
全局变量

全局变量使用小写字母开头。

如果变量值可以被gn args修改，则需要使用declare_args来声明，否则不要使用declare_args。

# 例2
declare_args() {
  # 可以通过gn args来修改some_feature的值
  some_feature = false
}
目标命名

目标命名采用小写字母+下划线的命名方式。

模板中的子目标命名方式采用"${target_name}+双下划线+后缀"的命名方式。这样做有两点好处：

  • 加入"${target_name}"可以防止子目标重名。

  • 加入双下划线可以很方便地区分出子目标属于哪一个模块，方便在出现问题时快速定位。

    # 例3
template("ohos_shared_library") {
  # "{target_name}"(主目标名)+"__"(双下划线)+"notice"(后缀)
  _notice_target = "${target_name}__notice"
  collect_notice(_notice_target) {
    ...
  }
  shared_library(target_name) {
    ...
  }
}
自定义模板的命名

推荐采用动宾短语的形式来命名。

# 例4
# Good
template("compile_resources") {
  ...
}

格式化

gn脚本在提交之前需要执行格式化。格式化可以保证代码对齐，换行等风格的统一。使用gn自带的format工具即可。命令如下：

$ gn format path-to-BUILD.gn

gn format会按照字母序对import文件做排序，如果想保证import的顺序，可以添加空注释行。

假设原来的import顺序为：

# 例5
import("//b.gni")
import("//a.gni")

经过format之后变为：

import("//a.gni")
import("//b.gni")

如果想保证原有的import顺序，可以添加空注释行。

import("//b.gni")
# Comment to keep import order
import("//a.gni")

编码实践

实践原则

编译脚本实质上完成了两件工作：

  1. 描述模块之间依赖关系（deps）

    实践过程中，最常出现的问题是依赖关系缺失。

  2. 描述模块编译的规则(rule)

    实践过程中，容易出现的问题是输入和输出不明确。

依赖缺失会导致两个问题：

  • 概率性编译错误

    # 例6
# 依赖关系缺失，导致概率性编译出错
shared_library("a") {
  ...
}
shared_library("b") {
  ...
  ldflags = [ "-la" ]
  deps = []
  ...
}
group("images") {
  deps = [ ":b" ]
}

    上面的例子中，libb.so在链接的时候会链接liba.so，实质上构成b依赖a，但是b的依赖列表（deps）却没有声明对a的依赖。由于编译是并发执行的，如果libb.so在链接的时候liba.so还没有编译出来，就会出现编译错误。

    由于liba.so也有可能在libb.so之前编译出来，所以依赖缺失导致的编译错误是概率性的。

  • 依赖关系缺失导致模块没有参与编译

    还是上面的例子，如果我们指定ninja编译目标为images，由于images仅仅依赖b，所以a不会参与编译。由于b实质上依赖a, 这时b在链接时会出现必现错误。

有一种不太常见的问题是过多的依赖。过多的依赖会降低并发，导致编译变慢。见下面的例子:

_compile_js_target不需要依赖 _compile_resource_target，增加这层依赖，会导致 _compile_js_target在 _compile_resource_target编译完成之后才能开始编译。

# 例7
# 过多的依赖导致编译变慢
template("too_much_deps") {
  ...
  _gen_resource_target = "${target_name}__res"
  action(_gen_resource_target) {
    ...
  }

  _compile_resource_target = "${target_name}__compile_res"
  action(_compile_resource_target) {
    deps = [":$_gen_resource_target"]
    ...
  }

  _compile_js_target = "${target_name}__js"
  action(_compile_js_target) {
    # 这个deps不需要
    deps = [":$_compile_resource_target"]
  }
}

输入不明确会导致：

  • 代码修改了，但增量编译时却没有参与编译。
  • 当使用缓存时，代码发生变化，但是缓存仍然命中。

下面的例子中，foo.py引用了bar.py中的函数。bar.py实质上是foo.py的输入，需要将bar.py添加到implict_input_action的input或者depfile中去。否则，修改bar.py，模块implict_input_action将不会重新编译。

# 例8
action("implict_input_action") {
  script = "//path-to-foo.py"
  ...
}

#!/usr/bin/env
# Contents of foo.py
import bar
...
bar.some_function()
...

输出不明确会导致：

  • 隐式的输出
  • 当使用缓存时，隐式输出无法从缓存中获得

下面的例子中，foo.py会生成两个文件，a.out和b.out，但是implict_output_action的输出只声明了a.out。这种情况下，b.out实质上就是一个隐式输出。缓存中只会存储a.out，不会存储b.out，当缓存命中时，b.out就编译不出来了。

# 例9
action("implict_output_action") {
  outputs = ["${target_out_dir}/a.out"]
  script = "//path-to-foo.py"
  ...
}

#!/usr/bin/env
# Contents of foo.py
...
write_file("b.out")
write_file("a.out")
...

模板

不要使用gn的原生模板，使用编译子系统提供的模板

所谓gn原生模板，是指source_set，shared_library, static_library, action, executable，group这六个模板。

不推荐使用原生模板的原因有二：

  • 原生模板是最小功能模板，无法提供external_deps的解析，notice收集，安装信息生成等的额外功能，这些额外功能最好是随着模块编译时同时生成，所以必须对原生模板做额外的扩展才能满足实际的需求。

  • 当输入文件依赖的文件发生变化时，gn原生的action模板不能自动感知到这种变化，无法重新编译。见例8

    原生模板和编译子系统提供的模板之间的对应关系:

编译子系统提供的模板原生模板
ohos_shared_libraryshared_library
ohos_source_setsource_set
ohos_executableexecutable
ohos_static_librarystatic_library
action_with_pydepsaction
ohos_groupgroup

使用python脚本

action中的script推荐使用python脚本，不推荐使用shell脚本。相比于shell脚本，python脚本：

  • python语法友好，不会因为少写一个空格就导致奇怪的错误。
  • python脚本有很强的可读性。
  • 可维护性强，可调试。
  • OpenHarmony对python任务做了缓存，可以加快编译速度。

rebase_path

  • 仅在向action的参数列表中（args）调用rebase_path。

    # 例10
template("foo") {
  action(target_name) {
    ...
    args = [
      # 仅在args中调用rebase_path
      "--bar=" + rebase_path(invoker.bar, root_build_dir),
      ...
    ]
    ...
  }
}

foo("good") {
  bar = something
  ...
}

  • 同一变量做两次rebase_path会出现意想不到的结果。

    # 例11
template("foo") {
  action(target_name) {
    ...
    args = [
      # bar被执行了两次rebase_path, 传递的bar的值已经不对了
      "--bar=" + rebase_path(invoker.bar, root_build_dir),
      ...
    ]
    ...
  }
}

foo("bad") {
  # 不要在这里调用rebase_path
  bar = rebase_path(some_value，root_build_dir)
  ...
}

模块间数据分享

模块间数据分享是很常见的事情，比如A模块想要知道B模块的输出和deps。

  • 同一BUILD.gn之间数据分享

    同一BUILD.gn之间数据可以通过定义全局变量的方式来共享。

    下面的例子中，模块a的输出是模块b的输入，可以通过定义全局变量的方式来共享给b

    # 例12
_output_a = get_label_info(":a", "out_dir") + "/a.out"
action("a") {
  outputs = _output_a
  ...
}
action("b") {
  inputs = [_output_a]
  ...
}

  • 不同BUILD.gn之间数据分享

    不同BUILD.gn之间传递数据，最好的办法是将需要共享的数据保存成文件，然后不同模块之间通过文件来传递和共享数据。这种场景比较复杂，读者可以参照OpenHarmony的hap编译过程的write_meta_data。

forward_variable_from

  • 自定义模板需要首先将testonly传递（forward）进来。因为该模板的target有可能被testonly的目标依赖。

    # 例13
# 自定义模板首先要传递testonly
template("foo") {
  forward_variable_from(invoker, ["testonly"])
  ...
}

  • 不推荐使用*来forward变量，需要的变量应该显式地，一个一个地被forward进来。

    # 例14
# Bad，使用*forward变量
template("foo") {
  forward_variable_from(invoker, "*")
  ...
}

# Good， 显式地，一个一个地forward变量
template("bar") {
  # 
  forward_variable_from(invoker, [
                                     "testonly",
                                     "deps",
                                     ...
                                   ])
  ...
}

target_name

target_name会随着作用域变化而变化，使用时需要注意。

# 例15
# target_name会随着作用域变化而变化
template("foo") {
  # 此时打印出来的target_name为"${target_name}"
  print(target_name)
  _code_gen_target = "${target_name}__gen"
  code_gen(_code_gen_target) {
    # 此时打印出来的target_name为"${target_name}__gen"
    print(target_name)
    ...
  }
  _compile_gen_target = "${target_name}__compile"
  compile(_compile_gen_target) {
    # 此时打印出来的target_name为"${target_name}__compile"
    print(target_name)
    ...
  }
  ...
}

public_configs

如果模块需要向外export头文件，请使用public_configs。

# 例16
# b依赖a，会同时继承a的headers
config("headers") {
  include_dirs = ["//path-to-headers"]
  ...
}
shared_library("a") {
  public_configs = [":headers"]
  ...
}
executable("b") {
  deps = [":a"]
  ...
}

template

自定义模板中必须有一个子目标的名字是target_name。该子目标会作为template的主目标。其他子目标都应该被主目标依赖，否则子目标不会被编译。

# 例17
# 自定义模板中必须有一个子目标的名字是target_name
template("foo") {
  _code_gen_target = "${target_name}__gen"
  code_gen(_code_gen_target) {
    ...
  }
  _compile_gen_target = "${target_name}__compile"
  compile(_compile_gen_target) {
    # 此时打印出来的target_name为"${target_name}__compile"
    print(target_name)
    ...
  }
  ...
  group(target_name) {
    deps = [
    # 由于_compile_gen_target依赖了_code_gen_target，所以主目标只需要依赖_compile_gen_target即可。
      ":$_compile_gen_target"
    ]
  }
}

set_source_assignment_filter

set_source_assignment_filter除了可以过滤sources，还可以用来过滤其他变量。过滤完成后记得将过滤器和sources置空。

# 例18
# 使用set_source_assignment_filter过滤依赖, 挑选label符合*:*_res的添加到依赖列表中
_deps = []
foreach(_possible_dep, invoker.deps) {
  set_source_assignment_filter(["*:*_res"])
  _label = get_label_info(_possible_dep, "label_no_toolchain")
  sources = []
  sources = [ _label ]
  if (sources = []) {
    _deps += _sources
  }
}
sources = []
set_source_assignment_filter([])

最新版本上set_source_assignment_filter被filter_include和filter_exclude取代。

部件内依赖采用deps，跨部件依赖采用external_deps

  • 部件在OpenHarmony上指能提供某个能力的一组模块。

  • 在模块定义的时候可以声明part_name，用来表明当前模块属于哪个部件。

  • 每个部件会声明其inner_kits，供其他部件调用。部件inner_kits的声明见源码中的bundle.json。

  • 部件间依赖只能依赖inner_kits，不能依赖非inner_kits的模块。

  • 如果a模块和b模块的part_name相同，那么a、b模块属于同一个部件，a，b模块之间的依赖关系可以用deps来声明。

  • 如果a、b模块的part_name不同，那么a、b模块不属于同一个部件，a、b模块之间的依赖关系需要通过external_deps来声明，依赖方式为"部件名:模块名"的方式。见例19。

    # 例19
shared_library("a") {
  ...
  external_deps = ["part_name_of_b:b"]
  ...
}

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2313291.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

STM32之BKP

STM32之BKP

VBAT备用电源。接的时候和主电源共地，正极接在一起，中间连接一个100nf的电容。BKP是RAM存储器。 四组VDD都要接到3.3V的电源上，要使用备用电池，就把电池正极接到VBAT，负极跟主电源共地。 TEMPER引脚先加一个默认的上拉…
阅读更多...
c++的基础排序算法

c++的基础排序算法

一、快速排序 1. 选择基准值（Pivot） 作用 ：从数组中选择一个元素作为基准（Pivot），用于划分数组。常见选择方式 ： 固定选择最后一个元素（如示例代码）。随机选择&#xf…
阅读更多...
基于Spring3的抽奖系统

基于Spring3的抽奖系统

注：项目git仓库地址：demo.lottery 小五Z/Spring items - 码云 - 开源中国 目录 注：项目git仓库地址：demo.lottery 小五Z/Spring items - 码云 - 开源中国 项目具体代码可参考仓库源码，本文只讲解重点代码逻辑 一…
阅读更多...
基于qiime2的16S数据分析全流程：从导入数据到下游分析一条龙

基于qiime2的16S数据分析全流程：从导入数据到下游分析一条龙

目录 创建metadata 把数据导入qiime2 去除引物序列 双端合并 （dada2不需要） 质控 （dada2不需要） 使用deblur获得特征序列 使用dada2生成代表序列与特征表 物种鉴定 可视化物种鉴定结果 构建进化树（ITS一般不构建进化树…
阅读更多...
【Linux系统编程】基本IO函数

【Linux系统编程】基本IO函数

目录 1、open 函数2、create 函数3、write 函数4、read 函数5、lseek 函数6、access 函数7、unlink 函数8、remove 函数9、fcntl 函数写锁互斥锁示例读锁共享锁示例 1、open 函数 头文件 #include<sys/types.h> #include<sys/stat.h>#include<fcntl.h>…
阅读更多...
Deepseek应用技巧-chatbox搭建前端问答

Deepseek应用技巧-chatbox搭建前端问答

目标&#xff1a;书接上回&#xff0c;由于本地私有化部署了deepseek的大模型&#xff0c;那怎么能够投入生产呢&#xff0c;那就必须有一个前端的应用界面&#xff0c;好在已经有很多的前人已经帮我们把前段应用给搭建好了&#xff0c;我们使用就可以啦&#xff0c;今天我们就…
阅读更多...
OpenAI API模型ChatGPT各模型功能对比，o1、o1Pro、GPT-4o、GPT-4.5调用次数限制附ChatGPT订阅教程

OpenAI API模型ChatGPT各模型功能对比，o1、o1Pro、GPT-4o、GPT-4.5调用次数限制附ChatGPT订阅教程

本文包含OpenAI API模型对比页面以及ChatGPT各模型功能对比表 - 截至2025最新整理数据&#xff1a;包含模型分类及描述&#xff1b;调用次数限制&#xff1b; 包含模型的类型有&#xff1a; Chat 模型&#xff08;如 GPT-4o、GPT-4.5、GPT-4&#xff09;专注于对话&#xff0c…
阅读更多...
Fast DDS Security--秘钥交换

Fast DDS Security--秘钥交换

Fast DDS Security模块中默认使用Diffie-Hellman算法进行秘钥交换。Diffie-Hellman 算法&#xff08;简称 DH 算法&#xff09;是一个非常重要的加密协议&#xff0c;用于在不安全的通信通道中安全地交换密钥。该算法通过利用数学中的离散对数问题来生成共享密钥&#xff0c;使…
阅读更多...
从0开始的操作系统手搓教程33：挂载我们的文件系统

从0开始的操作系统手搓教程33：挂载我们的文件系统

目录 代码实现 添加到初始化上 上电看现象 挂载分区可能是一些朋友不理解的——实际上挂载就是将我们的文件系统封装好了的设备&#xff08;硬盘啊&#xff0c;SD卡啊&#xff0c;U盘啊等等&#xff09;&#xff0c;挂到我们的默认分区路径下。这样我们就能访问到了&#xff…
阅读更多...
基于muduo+mysql+jsoncpp的简易HTTPWebServer

基于muduo+mysql+jsoncpp的简易HTTPWebServer

一、项目介绍 本项目基于C语言、陈硕老师的muduo网络库、mysql数据库以及jsoncpp&#xff0c;服务器监听两个端口&#xff0c;一个端口用于处理http请求&#xff0c;另一个端口用于处理发送来的json数据。 此项目在实现时&#xff0c;识别出车牌后打包为json数据发送给后端服务…
阅读更多...
【Go学习实战】03-2-博客查询及登录

【Go学习实战】03-2-博客查询及登录

【Go学习实战】03-2-博客查询及登录 读取数据库数据初始化数据库首页真实数据分类查询分类查询测试 文章查询文章查询测试 分类文章列表测试 登录功能登录页面登录接口获取json参数登录失败测试 md5加密jwt工具 登录成功测试 文章详情测试 读取数据库数据 因为我们之前的数据都…
阅读更多...
《Python实战进阶》No20: 网络爬虫开发：Scrapy框架详解

《Python实战进阶》No20: 网络爬虫开发：Scrapy框架详解

No20: 网络爬虫开发&#xff1a;Scrapy框架详解 摘要 本文深入解析Scrapy核心架构&#xff0c;通过中间件链式处理、布隆过滤器增量爬取、Splash动态渲染、分布式指纹策略四大核心技术&#xff0c;结合政府数据爬取与动态API逆向工程实战案例&#xff0c;构建企业级爬虫系统。…
阅读更多...
Linux：多线程（单例模式，其他常见的锁，读者写者问题）

Linux：多线程（单例模式，其他常见的锁，读者写者问题）

目录 单例模式 什么是设计模式 单例模式介绍 饿汉实现方式和懒汉实现方式 其他常见的各种锁 自旋锁 读者写者问题 逻辑过程 接口介绍 单例模式 什么是设计模式 设计模式就是一些大佬在编写代码的过程中&#xff0c;针对一些经典常见场景&#xff0c;给定对应解决方案&…
阅读更多...
【氮化镓】高输入功率应力诱导的GaN 在下的退化LNA退化

【氮化镓】高输入功率应力诱导的GaN 在下的退化LNA退化

2019年，中国工程物理研究院电子工程研究所的Tong等人基于实验与第一性原理计算方法，研究了Ka波段GaN低噪声放大器（LNA）在高输入功率应力下的退化机制。实验结果表明，在27 GHz下施加1 W连续波（CW）输入功率应力后，LNA的增益下降约1 dB，噪声系数（NF）增加约0.7 dB。进一…
阅读更多...
Javaweb后端文件上传@value注解

Javaweb后端文件上传@value注解

文件本地存储磁盘 阿里云oss准备工作 阿里云oss入门程序 要重启一下idea&#xff0c;上面有cmd 阿里云oss案例集成 优化 用spring中的value注解
阅读更多...
git规范提交之commitizen conventional-changelog-cli 安装

git规范提交之commitizen conventional-changelog-cli 安装

一、引言 使用规范的提交信息可以让项目更加模块化、易于维护和理解&#xff0c;同时也便于自动化工具&#xff08;如发布工具或 Changelog 生成器&#xff09;解析和处理提交记录。 通过编写符合规范的提交消息&#xff0c;可以让团队和协作者更好地理解项目的变更历史和版本…
阅读更多...
Java/Kotlin逆向基础与Smali语法精解

Java/Kotlin逆向基础与Smali语法精解

1. 法律警示与道德边界 1.1 司法判例深度剖析 案例一&#xff1a;2021年某游戏外挂团伙刑事案 犯罪手法&#xff1a;逆向《王者荣耀》通信协议&#xff0c;修改战斗数据包 技术细节&#xff1a;Hook libil2cpp.so的SendPacket函数 量刑依据&#xff1a;非法经营罪&#xff…
阅读更多...
非软件开发项目快速上手：14款管理软件精选

非软件开发项目快速上手：14款管理软件精选

文章介绍了以下14款项目管理系统&#xff1a;1.Worktile&#xff1b;2.Teambition&#xff1b;3.Microsoft Project&#xff1b;4.Forbes&#xff1b;5.WorkOtter&#xff1b;6.Trello&#xff1b;7.Smartsheet&#xff1b;8.Taiga&#xff1b;9.ClickUp&#xff1b;10.Monday.…
阅读更多...
夸父工具箱(安卓版) 手机超强工具箱

夸父工具箱(安卓版) 手机超强工具箱

如今&#xff0c;人们的互联网活动日益频繁&#xff0c;导致手机内存即便频繁清理&#xff0c;也会莫名其妙地迅速填满&#xff0c;许多无用的垃圾信息悄然占据空间。那么&#xff0c;如何有效应对这一难题呢&#xff1f;答案就是今天新推出的这款工具软件&#xff0c;它能从根…
阅读更多...
混元图生视频-腾讯混元开源的图生视频模型

混元图生视频-腾讯混元开源的图生视频模型

混元图生视频是什么 混元图生视频是腾讯混元推出的开源图生视频模型&#xff0c;用户可以通过上传一张图片进行简短描述&#xff0c;让图片动起来生成5秒的短视频。模型支持对口型、动作驱动和背景音效自动生成等功能。模型适用于写实、动漫和CGI等多种角色和场景&#xff0c;…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023