#夏日挑战赛#交叉编译（二）-- openharmony编译分解原创

挖墙脚的农民工

发布于 2022-7-15 13:56

浏览

4收藏

目的

openharmony社区已经已经提供了当前编译方法，我们通过配置对应设备并执行脚本便能通过通过编译获取到我们所需的版本。对于编译的过程与编译的细节我们似乎不需要关心，除非出现bug,当然有社区有对应的大牛的维护这种概率极低，似乎去了解和拆分openharmony编译成为一种可有可无的活。其实不然，拆解openharmony编译过程，我们更能了解编译的细节，熟悉并熟练去掌握gn + ninja 编译的框架，更具有价值意义在于独立的三方件的管理和打通openharmony与linux 组件的共用(当然以上纯属瞎扯，当然学习还是可以的)，

准备

openhamrony 编译原理

1、prebuilts_download.sh

prebuilts_download.sh中主要是用于下载与编译相关的编译工具，当然其中最使用华为配置好的相关编译工具是最好途径，由于编译的依赖关系和编译工具之间的版本关系，如果使用单独的工具需要及其了解其中编译原理。当前openharmony 中rk3568中由于存在两种编译方式即内核的编译和用户态程序的编译导致编译很复杂。

prebuilts_download.sh 脚本部分代码
copy_config="""
prebuilts/sdk/js-loader/build-tools,${tool_repo}/openharmony/compiler/ace-loader/1.0/ace-loader-1.0.tar.gz
prebuilts/build-tools/common,${tool_repo}/openharmony/compiler/restool/2.007/restool-2.007.tar.gz
prebuilts/cmake,${tool_repo}/openharmony/compiler/cmake/3.16.5/${host_platform}/cmake-${host_platform}-x86-3.16.5.tar.gz
prebuilts/build-tools/${host_platform}-x86/bin,${tool_repo}/openharmony/compiler/gn/1717/${host_platform}/gn-${host_platform}-x86-1717.tar.gz
prebuilts/build-tools/${host_platform}-x86/bin,${tool_repo}/openharmony/compiler/ninja/1.10.1/${host_platform}/ninja-${host_platform}-x86-1.10.1.tar.gz
prebuilts/clang/ohos/${host_platform}-x86_64,${tool_repo}/openharmony/compiler/clang/10.0.1-480513/${host_platform}/clang-480513-${host_platform}-x86_64.tar.bz2
prebuilts/ark_tools,${tool_repo}/openharmony/compiler/llvm_prebuilt_libs/ark_js_prebuilts_20220425.tar.gz
"""

linux_copy_config="""
prebuilts/cmake,${tool_repo}/openharmony/compiler/cmake/3.16.5/windows/cmake-windows-x86-3.16.5.tar.gz
prebuilts/mingw-w64/ohos/linux-x86_64,${tool_repo}/openharmony/compiler/mingw-w64/7.0.0/clang-mingw.tar.gz
prebuilts/gcc/linux-x86/arm/gcc-linaro-7.5.0-arm-linux-gnueabi,${tool_repo}/openharmony/compiler/prebuilts_gcc_linux-x86_arm_gcc-linaro-7.5.0-arm-linux-gnueabi/1.0/prebuilts_gcc_linux-x86_arm_gcc-linaro-7.5.0-arm-linux-gnueabi.tar.gz
prebuilts/gcc/linux-x86/aarch64,${tool_repo}/openharmony/compiler/prebuilts_gcc_linux-x86_arm_gcc-linaro-7.5.0-arm-linux-gnueabi/1.0/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz
prebuilts/previewer/windows,${tool_repo}/openharmony/develop_tools/previewer/3.2.2.5/previewer-3.2.2.5-Master-20220527.win.tar.gz
prebuilts/clang/ohos/windows-x86_64,${tool_repo}/openharmony/compiler/clang/10.0.1-480513/windows/clang-480513-windows-x86_64.tar.bz2
prebuilts/clang/ohos/windows-x86_64,${tool_repo}/openharmony/compiler/clang/10.0.1-480513/windows/libcxx-ndk-480513-windows-x86_64.tar.bz2
prebuilts/clang/ohos/${host_platform}-x86_64,${tool_repo}/openharmony/compiler/clang/10.0.1-480513/${host_platform}/libcxx-ndk-480513-${host_platform}-x86_64.tar.bz2
prebuilts/gcc/linux-x86/esp,${tool_repo}/openharmony/compiler/gcc_esp/2019r2-8.2.0/linux/esp-2019r2-8.2.0.zip
prebuilts/gcc/linux-x86/csky,${tool_repo}/openharmony/compiler/gcc_csky/v3.10.29/linux/csky-v3.10.29.tar.gz
prebuilts/python,${tool_repo}/openharmony/compiler/python/3.9.2/${host_platform}/python-${host_platform}-x86-3.9.2_20200510.tar.gz
"""

darwin_copy_config="""
prebuilts/previewer/darwin,${tool_repo}/openharmony/develop_tools/previewer/3.2.2.5/previewer-3.2.2.5-Master-20220527.mac.tar.gz
prebuilts/clang/ohos/${host_platform}-x86_64,${tool_repo}/openharmony/compiler/clang/10.0.1-480513/${host_platform}/libcxx-ndk-480513-${host_platform}-x86_64.tar.bz2
prebuilts/python,${tool_repo}/openharmony/compiler/python/3.9.2/${host_platform}/python-${host_platform}-x86-3.9.2_202205071615.tar.gz
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

2、用户态程序编译工具

通过 ls /out/rk3568/ 我们发现rk3586开发板中编译方式中存在clang_x64目录，即clang也参与了编译，其实通过增加打印编译参数我们发现。openhamrony 当前编译主要通过llvm + clang 进行用户态相关程序的编译（内核怎么编译的没去了解），可以参考这篇文章
#夏日挑战赛#交叉编译（二）-- openharmony编译分解-鸿蒙开发者社区

3、编译依赖关系

编译依赖关系并非指编译器工具之间的依赖关系。前面已经发文提到过rk3568编译过程中clang(llvm)编译器通过配置将对应的./third_party/musl/crt目录下面的.s 文件生成.o 文件，然后加入到libc.so的编译，最后参与到用户态程序编译。当然通过cat build/common/musl/BUILD.gn
#夏日挑战赛#交叉编译（二）-- openharmony编译分解-鸿蒙开发者社区
可以看到开发板运行依赖于对应的musl库

openhamrony 编译过程分析

openharmony 通过执行编译脚本，便可启动编译。通过./build.sh --product-name rk3568 --build-target=helloworld可以单独编译helloworld，通过cat ./build.sh 我们可以了解到，openharmony编译通过python进行拉起。
#夏日挑战赛#交叉编译（二）-- openharmony编译分解-鸿蒙开发者社区
tools_checker.py 脚本用户环境相关检测，entry.py 为实际编译入口。
gn和ninja编译往往需要进行环境的配置，通过 gn gen 命令可以进行gn编译环境的构建，而ninja -C out 则可以编译已经构建好的编译环境，而在openharmony 编译过程中，entry.py 进入之后通过python脚本多做了一步编译环境的配置。为更清晰分析编译过程。我们可以在build/lite/hb_internal/common/utils.py 中的exec_command 函数处增加断点，通过分析脚本来分析编译环境相关的配置。
#夏日挑战赛#交叉编译（二）-- openharmony编译分解-鸿蒙开发者社区
配置好断点之后，我们通过重新执行脚本。

通过打印print cmd 我们可以看到，执行hb 之后，首先执行的配置是通过 [‘ccache’, ‘-M’, ‘50G’]
配置也是对应日志显示信息。当然在此之前，环境相关配置会在out/preloader/rk3568目录下面保存到相关的文件中。
#夏日挑战赛#交叉编译（二）-- openharmony编译分解-鸿蒙开发者社区
通过执行按下c + enter 我们继续查阅下一步所需执行的命令。

我们可以看到这一步主要是gn + gen 编译环境的构建，当然其中具体怎么跑的，需要分析pyhton脚本（还没有去瞄一下）。再次执行 c + enter 我们继续查阅下一步所需执行的命令。
#夏日挑战赛#交叉编译（二）-- openharmony编译分解-鸿蒙开发者社区
通print cmd 我们发现这一步主要用于ninja 编译的开始，当然也可以通过python找到对应脚本的配置。这里我们已经很明确的将openharmony编译拆分成了3个部分，即通过python脚本分解为编译前环境配置，gn编译构建和ninja 构建环境编译3个部分。