写点什么

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

  • 2022 年 3 月 16 日
  • 本文字数:2928 字

    阅读完需:约 10 分钟

本文分享自华为云社区《移植案例与原理 - 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" ]}
复制代码

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

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


在生成的文件 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_dir
if (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'" }
复制代码

4、名为 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" ] } } }
复制代码

参考站点


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


发布于: 刚刚阅读数: 2
用户头像

提供全面深入的云计算技术干货 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算! 传送门:https://bbs.huaweicloud.com/

评论

发布
暂无评论
Open Harmony移植:build lite编译构建过程_编译_华为云开发者社区_InfoQ写作平台