本文分享自华为云社区《移植案例与原理 - build lite编译构建过程》，作者： zhushy。

配置完毕产品解决方案、芯片开发板解决方案，就可以执行 hb build进行编译。但是产品解决方案代码是如何被调用编译的？
芯片开发板解决方案代码是如何被调用编译的？内核代码如何被调用编译的？解决了这些疑惑，会对build lite编译构建过程有个更深入的理解。

1、产品解决方案代码是如何被调用编译的

在文件build\lite\BUILD.gn配置文件中的构建目标//build/lite:product的代码片段如下，可以看出产品解决方案是被//build/lite:product调用的。其中⑴处的ohos_build_target，由hb build -T XX 构建参数指定，一般不指定时为空。

    group("product") {deps = []# build product, skip build single component scenario.
⑴  if (ohos_build_target == "") {deps += [ "${product_path}" ]}}

//build/lite:product 又进一步被什么模块调用？在恒玄的代码配置文件device\soc\bestechnic\bes2600\BUILD.gn中使用了，非恒玄的没有调用//build/lite:product。所以，除了//build/lite:product，还有其他调用编译产品解决方案代码的地方。

以vendor\goodix\gr5515_sk_iotlink_demo为例，来了解下什么地方会调用编译产品解决方案代码。产品解决方案根目录下有文件vendor\goodix\gr5515_sk_iotlink_demo\ohos.build，片段如下。可以看到，有子系统subsystem和部件信息parts。

{"parts": {"product_gr5515_sk_iotlink_demo": {"module_list": ["//vendor/goodix/gr5515_sk_iotlink_demo:gr5515_sk_iotlink_demo","//vendor/goodix/gr5515_sk_iotlink_demo:image"]}},"subsystem": "product_gr5515_sk_iotlink_demo"
}

在编译构建时，会基于ohos.build文件，解析子系统和部件信息，生成到out\gr5515_sk\gr5515_sk_iotlink_demo\build_configs\parts_info\subsystem_parts.json文件中，片段如下。这些解析出来的子系统和部件信息，编译构建构建hb会组织进行编译构建。

  "product_gr5515_sk_iotlink_demo": ["product_gr5515_sk_iotlink_demo"],

2、芯片开发板解决方案代码是如何被调用编译的

在文件kernel\liteos_m\BUILD.gn中定义的名为modules构建目标，这个modules构建目标依赖芯片开发板解决方案的代码。。⑴处判断芯片和开发板是否是否进行了文件夹解耦，如果开发板路径包含“/board/”,说明soc和board进行了解耦。根据是否解耦，依赖的芯片开发板的构建配置文件路径是不同的，见⑵。

    # board and soc decoupling feature, device_path should contains board
⑴  BOARD_SOC_FEATURE = device_path != string_replace(device_path, "/board/", "")......group("modules") {deps = ["arch","components","kal","kernel","testsuites","utils",HDFTOPDIR,]⑵  if (BOARD_SOC_FEATURE) {deps += [ "//device/board/$device_company" ]deps += [ "//device/soc/$LOSCFG_SOC_COMPANY" ]} else {if (HAVE_DEVICE_SDK) {deps += [ device_path ]}}}

名为modules构建目标又被libkernel构建目标、进一步被名为kernel的构建目标调用，如下所示。内核的kernel构建目标如何被调用，下一小节分析。

static_library("libkernel") {deps = [ ":modules" ]complete_static_lib = false
}group("kernel") {deps = [ ":libkernel" ]
}

4、内核代码如何被调用编译的

上文分析了产品解决方案、芯片开发板解决方案如何被调用的。本小节，追踪下内核代码是如何被调用编译的。

在生成的文件out\v200zr\display_demo\build_configs\kernel\liteos_m\BUILD.gn中，会调用名为kernel、build_kernel_image的构建目录。怎么生成的这个文件，需要研究下hb的代码，深入了解下后台的机制，希望后续有时间可以继续深入一些。

    import("//build/ohos/ohos_kits.gni")import("//build/ohos/ohos_part.gni")import("//build/ohos/ohos_test.gni")ohos_part("liteos_m") {subsystem_name = "kernel"module_list = ["//kernel/liteos_m:kernel","//kernel/liteos_m:build_kernel_image",]origin_name = "liteos_m"variant = "phone"}

构建目标build_kernel_image可以生成bin文件，该目标依赖copy_liteos，copy_liteos依赖liteos构建目标，该目标会进一步调用//build/lite:ohos。//build/lite:ohos文件会依次调用各个子系统和部件的构建目标。

    executable("liteos") {configs += [":public",":los_config",]ldflags = ["-static","-Wl,--gc-sections","-Wl,-Map=$liteos_name.map",]output_dir = target_out_dirif (liteos_kernel_only) {deps = [ ":kernel" ]} else {deps = [ "//build/lite:ohos" ]}}copy("copy_liteos") {deps = [ ":liteos" ]sources = [ "$target_out_dir/unstripped/bin/liteos" ]outputs = [ "$root_out_dir/$liteos_name" ]}build_ext_component("build_kernel_image") {deps = [ ":copy_liteos" ]exec_path = rebase_path(root_out_dir)objcopy = "${compile_prefix}objcopy$toolchain_cmd_suffix"objdump = "${compile_prefix}objdump$toolchain_cmd_suffix"command = "$objcopy -O binary $liteos_name $liteos_name.bin"command +=" && sh -c '$objdump -t $liteos_name | sort >$liteos_name.sym.sorted'"command += " && sh -c '$objdump -d $liteos_name >$liteos_name.asm'"}

5、名为public的config

在文件kernel\liteos_m\BUILD.gn中，名为public的config定义如下。⑴处判断芯片和开发板是否是否进行了文件夹解耦，如果开发板路径包含“/board/”,说明soc和board进行了解耦。根据是否解耦，依赖的public的配置集的位置是不同的，见⑵。在芯片、开发板代码目录中的BUILD.gn文件中并没有发现config(“public”)，这个比较奇怪。

    # board and soc decoupling feature, device_path should contains board
⑴  BOARD_SOC_FEATURE = device_path != string_replace(device_path, "/board/", "")config("public") {configs = ["arch:public","kernel:public","kal:public","components:public","utils:public",]⑵  if (BOARD_SOC_FEATURE) {configs += [ "//device/board/$device_company:public" ]configs += [ "//device/soc/$LOSCFG_SOC_COMPANY:public" ]} else {if (HAVE_DEVICE_SDK) {configs += [ "$device_path:public" ]}}}

参考站点

OpenHarmony / build_lite
轻量和小型系统编译构建指导
轻量带屏解决方案之恒玄芯片移植案例

点击关注，第一时间了解华为云新鲜技术~

Open Harmony移植：build lite编译构建过程相关推荐

U-Boot 之四构建过程（Kconfig 配置 + Kbuild 编译）详解
在之前的博文 Linux 之八完整嵌入式 Linux 环境介绍及搭建过程详解中我们说了要一步步搭建整个嵌入式 Linux 运行环境,今天继续介绍 U-Boot 相关的内容.我所使用的硬件平台及 ...
APK构建过程-命令行编译
官方对APK构建过程的介绍官方 - 构建流程介绍典型 Android 应用模块的构建流程,按照以下常规步骤执行: 编译器将您的源代码转换成 DEX 文件(Dalvik 可执行文件,其中包括在 An ...
docker push很慢怎么办_如何加速 Docker Build 构建过程
Dockerfile docker 已经成为现代开发的基础技术, 而在 docker 开发流中, Dockerfile 是最基础的文件. 一个包括了系统配置.依赖安装.业务代码的 Dockerfile ...
HarmonyOS之深入解析编译构建的配置和代码混淆
一.概述编译构建是将 HarmonyOS 应用的源代码.资源.第三方库等打包生成 HAP 或者 APP 的过程.其中,HAP 可以直接运行在真机设备或者模拟器中:APP 则是用于应用上架到华为应用市 ...
Go 学习笔记（37）— 标准命令（go build 跨平台编译、交叉编译、go clean、go run、go fmt、go install、go get）
1. 标准命令简述 Go 本身包含来大量用于处理 Go 程序的命令和工具. 命令作用 build 用于编译指定的代码包或 Go 语言源码文件.命令源码文件会被编译成可执行文件,并存放到命令执行的目录 ...
编译+构建+链接+运行之间的关系分析
编译+构建+链接+运行之间的关系分析源文件+编译+部署+测试+打包 Maven+default: 验证(validate)+编译(compile)+测试(test)+打包(package)+验证(v ...
U-Boot 之一零基础编译 U-Boot 过程详解及编译后的使用说明
在之前的博文 Linux 之八完整嵌入式 Linux 环境介绍及搭建过程详解中我们说了要一步步搭建整个嵌入式 Linux 运行环境,今天就开始编译 U-Boot.我所使用的硬件平台及整个要搭建 ...
android Android项目构建过程
今天,简单讲讲android studio如何把写好的工程打包成apk的. 平时开发过程中我们通过android studio编写完成android项目之后直接点击 Run 'app'就可以在buil ...
vue 源码学习（一）目录结构和构建过程简介
Flow vue框架使用了Flow作为类型检查,来保证项目的可读性和维护性.vue.js的主目录下有Flow的配置.flowconfig文件,还有flow目录,指定了各种自定义类型. 在学习源码前可以 ...

Open Harmony移植：build lite编译构建过程