鸿蒙系统的编译流程及分析v1.0 - HarmonyOS技术社区 - 电子技术论坛 - 广受欢迎的专业电子论坛
分享 收藏 返回

[文章]

鸿蒙系统的编译流程及分析v1.0

文章转载自:liangkz

更新记录
2021.04.17v1.0初始版本

说明:
因为新接触鸿蒙系统的开发,我对鸿蒙的编译系统基本上没什么理解,都是凭着经验和百度一边学习一边总结的,本文是我在学习网上关于鸿蒙系统的编译相关资料后做的总结,经过了本人的实际操作验证,部分知识点可能还有理解不到位的地方,未来会持续更新。

1.准备工作
我的本地代码是基于最新发布的OpenHarmony 1.1.0 LTS(2021-04-01)版本抓取的,代码根目录OHOS1_1_0LTS:
        $repo init -u https://gitee.com/openharmony/manifest.git -b refs/tags/OpenHarmony_release_v1.1.0 --no-repo-verify
        $repo sync

我还有Hi3861_Wifiiot开发板和开发环境,如下:
在Linux环境下的DecEco IDE下创建新工程“Test_Wifiiot”,在“HPM”标签下找到“@ohos/wifi_iot”,点击“Install to project”选择“Test_Wifiiot”项目,开始下载并安装组件到项目里。

2.全编译+模块编译
2.1  OHOS1_1_0LTS的全代码编译
在代码根目录下执行:
引用: OHOS1_1_0LTS$ hb set
[OHOS INFO] Input code path: .
OHOS Which product do you need?  
ipcamera_hispark_pegasus@hisilicon
-> ipcamera_hispark_taurus@hisilicon
ipcamera_hispark_aries@hisilicon

这一步完成后,会在代码根目录下生成“ohos_config.json”文件,然后就可以开始编译了:
引用: OHOS1_1_0LTS$ hb build
OHOS1_1_0LTS$ python build.py
OHOS1_1_0LTS$ python build.py -p ipcamera_hispark_taurus@hisilicon

效果都是一样的。

第一次全编译了2491个文件,以后再操作上面的命令就不是全编译了,只编译需要编译的部分。

2.2  Test_Wifiiot项目的全编译
新下载的项目代码根目录下并没有“build.py”文件。
  1. $ hb set
会生成“ohos_config.json”,但没有完成配置,hb build 会失败。

可以执行
  1. $ln -s ./build/lite/build.py build.py
创建build.py的软链接,再执行
  1. $python build.py wifiiot
就可以正常编译了。

Test_Wifiiot项目还可以用DevEco IDE进行一键编译,操作步骤见官方的文档:
https://device.harmonyos.com/cn/ ... on-0000001050166905

2.3  OHOS1_1_0LTS的组件/仓库/Target编译

一开始,关于模块编译,我在网上搜到了:

《HarmonyOS单模块编译与源码导读》(Link: https://harmonyos.51cto.com/posts/3094 )

这篇文章(下文简称《导读》),仔细阅读,并对比本地代码OHOS1_1_0LTS查看了buildlite目录下,并没有上文所提到的compile.py文件和product目录,这个可能是鸿蒙系统迭代更新版本给拿掉了。

查看OHOS1_1_0LTSuildlite目录下的README_zh.md,虽然看到增加了-T的说明:
  1.     -T [TARGET [TARGET ...]], --target [TARGET [TARGET ...]]
  2.       Compile single target
但没做进一步使用说明,因为对鸿蒙的编译系统还没多少了解,我还是不大清楚如何使用操作。

官方文档“轻量和小型系统编译构建指导”:
https://device.harmonyos.com/cn/ ... es-0000001060646620
可能没有更新,甚至没有对“-T”参数的描述。

不过官方文档中“组件描述位于build/lite/components下”这句话倒提醒了我,去里面看了一下,原来这就是鸿蒙系统所有组件描述文件的存放位置,每个组件文件内又有多个【组件和target】的描述。

打开“applications.json”看一下,这里就有上面《导读》提到的东西:
  1.           <font size="4" color="Red">"component": "camera_sample_app",</font>
  2.           "description": "Camera related samples.",
  3.           "optional": "true",
  4.           "dirs": [
  5.             "applications/sample/camera/launcher",
  6.             "applications/sample/camera/cameraApp",
  7.             "applications/sample/camera/setting",
  8.             "applications/sample/camera/gallery",
  9.             "applications/sample/camera/media"
  10.           ],
  11.           "targets": [
  12.             <font size="4" color="Red">"//applications/sample/camera/launcher:launcher_hap",</font>
  13.             "//applications/sample/camera/cameraApp:cameraApp_hap",
  14.             "//applications/sample/camera/setting:setting_hap",
  15.             "//applications/sample/camera/gallery:gallery_hap",
  16.             "//applications/sample/camera/media:media_sample"
  17.           ],
赶紧操作一下:
  1. OHOS1_1_0LTS$ hb build -T //applications/sample/camera/launcher:launcher_hap
编译OK,不过时间还是有点长

官方文档说“组件即为gn中的编译单元,可以为静态库、动态库或可执行文件。”
编译构建流程图上也是写 hb build [component]
  1. OHOS1_1_0LTS$ hb build camera_sample_app
编译OK,但感觉与target编译以及最上面hb build是一样的效果~~

我还在OHOS1_1_0LTSapplicationssamplecameraREADME_zh.md 文档中看到对媒体子系统组件的使用说明:
单仓的编译构建,在根目录下进行单仓的构建和编译
  1. # 开发板选择
  2. hb set  
  3. # 单仓构建和编译
  4. hb build camera_lite
再查看一下buildlitecomponentsmultimedia.json,原来单仓编译就是组件编译,而Target编译,实际上看起来又与组件编译差别不大,有些组件本身就是一个target,有些组件分多个target。
  1.       "component": "camera_lite",
  2.       "description": "Camera service.",
  3.       "optional": "true",
  4.       "dirs": [
  5.         "foundation/multimedia/camera_lite",
  6.         "foundation/multimedia/utils/lite/hals"
  7.       ],
  8.       "targets": [
  9.         "//foundation/multimedia/camera_lite/frameworks:camera_lite"
  10.       ],

小结:
鸿蒙系统所有组件描述文件的存放在build/lite/components/目录下,每个组件文件内又有多个组件和target的描述。
组件/仓库编译指令:
  1. $hb build component_name
Target编译指令(可一次编译多个target,用&&连接):
  1. $hb build -T target_name
  2. $hb build -T target1_name&&target2_name

3.编译系统build目录结构
首先必须要仔细研读 buildliteREADME_zh.md 文档,文档上没有的地方,我这里补充一下我的理解,做成表格更容易管理。这个表格会在以后学习过程中根据新的理解做更新。

4.编译结果out目录结构

打开“os-release”文件查看:
  1. VERSION="OpenHarmony 1.0"
  2. RELEASE_TIME="2021-04-18 07:38:53"
分别是鸿蒙系统的版本号,和当次编译(内核?系统?)的时间

5.构建系统Gn+Ninja
在学习鸿蒙之前,我对Gn/Ninja并不了解,只是知道有这么个东西,因为用不到所以也没有去学习的动力。
这几天因为想深入了解一下鸿蒙的编译系统,就通过网络资源简单学习了一下,也只是知道了个大概,我看到的资料里觉得比较好的,有如下链接:

首先最重要的“gn help &lt;command&gt;”和官方文档“The Ninja build system”,随用随查。
【下文中对gn定义的关键字不再解释,请自行随时 gn help。】

《浅析鸿蒙中的Gn和Ninjia(一)》
Link: https://harmonyos.51cto.com/posts/2972
《HarmonyOS 2.0研究(1) -环境搭建及编译过程分析》【强烈推荐】【本文内简称为《过程分析》】
Link:https://my.oschina.net/u/2502829/blog/4613535
《#2020征文-开发板#鸿蒙liteos-a如何启动第一个用户进程init_lite》【本文内简称为《如何启动init_lite》】
Link:https://harmonyos.51cto.com/posts/1998#bkwz
《GN语法和操作》
Link:https://blog.csdn.net/yujiawang/article/details/72627138

为了快速理解Gn+Ninja是如何工作的,我自己做了一个 GnHelloWorld工程来做测试和验证,源代码放在gitee上:
https://gitee.com/liangkzgitee/GnProjs.git
压缩包也添加在本文附件里,请大家按readme.txt文档操作,逐步进行跟踪和分析。

readme.txt 文档内容如下:
引用: 这是一个最简单的Gn+Ninja构建系统的例子工程,通过这个简单的工程和下面的操作,学习Gn+Ninja构建系统是如何构建编译我们的源代码的。

原始工程目录如下:
GnHelloWorld/                  #工程根目录
    ├──build/                    #编译构建主目录
    │     └──config/               #编译相关的配置项
    │             ├──toolchans/         #编译工具链相关
    │             │     └──BUILD.gn      #编译选项、链接选项等等
    │             └──BUILDCONFIG.gn    #指定默认编译工具链
    ├──src/                      #源代码目录
    │     ├──BUILD.gn              #(*)
    │     └──hello.c                #(*)源代码
    ├──.gn                       #Gn构建系统入口
    ├──BUILD.gn                  #
    └──Readme.txt                #(*)本文

    Step1:
    在&quot;GnHelloWorld&quot;目录下执行:&quot;gn gen out&quot;命令后,会生成一个&quot;out&quot;目录,GnHelloWorld/

    ├──......[略]
    ├──out/
    │  ├──obj/
    │  │      └──src/
    │  │             └──hello.ninja    #编译hello.c的ninja脚本
    │  ├──args.gn              #构建参数
    │  ├──build.ninja         
    │  ├──build.ninja.d
    │  └──toolchain.ninja
    ├──......[略]

    Step2: [建议操作这步之前,先备份out目录,如: &quot;cp -r out out_bak&quot;]在&quot;GnHelloWorld&quot;目录下执行: &quot;ninja -C out&quot;,会在out目录下生成GnHelloWorld/

    ├──......[略]
    ├──out_bak/               #Step1 的 out 目录的副本
    │     ├──obj/
    │     │     └──src/
    │     │             └──hello.ninja
    │     ├──args.gn
    │     ├──build.ninja
    │     ├──build.ninja.d
    │     └──toolchain.ninja
    ├──out/                     #out目录有更新,见#
    │    ├──obj/
    │    │     ├──src
    │    │     │     ├──hello.ninja
    │    │     │     └──hello.o        #编译链工具根据规则生成的 .o
    │    │     └──all.stamp          #
    │    ├──.ninja_deps            #
    │    ├──.ninja_log             #
    │    ├──args.gn
    │    ├──build.ninja
    │    ├──build.ninja.d
    │    ├──hello                 #编译后生成的可执行文件
    │    └──toolchain.ninja
    ├──......[略]

    Step3:
    在&quot;GnHelloWorld&quot;目录下执行: 执行&quot;./out/hello&quot;,输出&quot;Hello Gn World!&quot;

    Step1做了如下工作:

    1.执行gn gen 时带的参数被记录下来,生成out/args.gn【本例不带args参数】

    2.找到 “.gn”文件并将其所在的目录设为“souce root”,解析该文件以获取buildconfig。

    3.执行buildconfig所指向的文件BUILDCONFIG.gn,设置一个默认的编译工具链,生成out/toolchain.ninja。

    4.加载“souce root”目录下的“BUILD.gn”文件,根据其内容加载它依赖的其它目录下的BUILD.gn文件,生成out/build.ninja.d。

    5.根据out/build.ninja.d中各个BUILD.gn的内容,递归解决各自的依赖关系,解决掉依赖关系之后,就在out/obj/对应目录下,生成“.ninja”,如例子中的“out/obj/src/hello.ninja”。

    6.解决掉所有的依赖关系后,在out/目录下生成一个“build.ninja”。

    Step2做了如下工作:

    根据上面的.ninja文件所定义的规则和依赖关系,依次编译出各自的中间文件,最终生成可执行文件“out/hello”。

    理解了上面的东西之后,你就可以开始进一步学习更复杂的东西了,可以参考Gn的官方文档,或者网络上的其它资源,自己动手做验证。

6.编译流程分析
我们repo/sync完整个鸿蒙代码后,要编译系统,一般做以下三步:
1. 首次编译,需要首先 hb set
2. 首次编译,hb build 会启动全编译
3. 修改某个文件,比如 init_lite 的main 文件main函数加行log,再次编译 hb build或者hb build init_lite。

这三步操作,鸿蒙的编译系统都做了哪些具体工作?
带着这个疑问,我希望能够抽丝剥茧,一步一步来确认,可能中间会有暂不理解的,先跳过,未来再做进一步完善。
可惜目前我对python的了解也不多,无法对相关脚本做非常详细的分析,对Gn构建系统的理解也还不够深入,无法给出理想的分析结果,所以只能先把我现在知道的写下来,以后学习过程中逐步补充完善。

6.1设置环境hb set
【查看/build/lite/README_zh.md】
设置OpenHarmony源码目录和要编译的产品,在代码根目录生成“ohos_config.json”文件。

具体 hb set命令怎么调用/build/lite/hb/目录下的相关脚本,再结合系统环境变量$PATH等相关必要信息来生成这个.json文件的,懂python的可以进去看一下。

打开“ohos_config.json”文件查看:
  1.     {
  2.       "root_path": "/home/lkz/Work/OHOS1_1_0LTS",
  3.       "board": "hispark_taurus",
  4.       "kernel": "liteos_a",
  5.       "product": "ipcamera_hispark_taurus",
  6.       "product_path": "/home/lkz/Work/OHOS1_1_0LTS/vendor/hisilicon/hispark_taurus",
  7.       "device_path": "/home/lkz/Work/OHOS1_1_0LTS/device/hisilicon/hispark_taurus/sdk_liteos"
  8.     }
这些将作为非常重要的参数交给下一步编译使用。

6.2全编译hb build
【查看/build/lite/README_zh.md】
编译产品、开发板或者组件。解决方案编译实现如下:
A. 读取开发板配置:主要包括开发板使用的编译工具链、编译链接命令和选项等。
B.  调用gn: 调用gn gen命令,读取产品配置(主要包括开发板、内核、选择的组件等)生成解决方案out目录和ninja文件。
C.  调用ninja:调用ninja -C out/company/product启动编译。
D.  系统镜像打包:将组件编译产物打包,制作文件系统镜像。
说的很“框架”,下面我们一步一步来看一下。

A. 检测/读取/配置所有的必要参数
包括但不限于以下列出来的几个文件:
  • ohos_config.json
  • Buildliteohos_var.gni   定义使用于所有组件的全局变量
  • devicehisiliconhispark_pegasussdk_liteosconfig.gni  这是编译LiteOS_A内核所需要用到的配置
  • vendorhisiliconhispark_taurusconfig.json  这是hisilicon提供的产品全量配置表:子系统、组件列表等等
  • 通过hb build传进去的参数,比如 -n 表示编译NDK,则会将ohos_build_ndk变量由默认的FALSE改为TRUE。

B. 调用gn gen命令生成out目录和ninja文件
很复杂,也很简单。
复杂是中间涉及到太多的Python和Gn语法,我暂时无法完整理解。
简单是因为我做过了上面的GnHelloWorld工程来做测试和分析,知道了框架。
更详细的分析过程,请看《过程分析》这篇文章。

下面是我对//build/lite/BUILD.gn这个文件中的 group(&quot;ohos&quot;) 的分解,最终得到&quot;ohos&quot;的完整的依赖关系:


C. 调用ninja启动编译
这里就开始根据上一步生成的 .ninja 文件里的规则调用编译工具链来编译各目录下的源文件了,生成 .o/.a/.so/可执行文件 等等,其中.so文件会先在outhispark_taurusipcamera_hispark_taurus目录下生成,等编译完之后会转移到outhispark_taurusipcamera_hispark_tauruslibsusr目录下,还生成了.ninja_log和.ninja_deps文件。

D. 打包制作系统镜像
【暂未清晰理解,略】

6.3增量编译hb build [component]
【暂未清晰理解,略】

附录一:hb build -T target的验证
【多图,见附件文档,此处略】

GnProjs.rar (20.87 KB)
(下载次数: 0, 2022-4-7 10:39 上传)

group(ohos)的分步解释.rar (2.61 KB)
(下载次数: 0, 2022-4-7 10:39 上传)

鸿蒙系统的编译流程及分析v1.0-2021.04.17.pdf (3.19 MB)
(下载次数: 0, 2022-4-7 10:39 上传)



更多回帖

×
发帖