OpenHarmony 移植：build lite 编译构建过程

配置完毕产品解决方案、芯片开发板解决方案，就可以执行 hb build 进行编译。但是产品解决方案代码是如何被调用编译的？

芯片开发板解决方案代码是如何被调用编译的？内核代码如何被调用编译的？解决了这些疑惑，会对 build lite 编译构建过程有个更深入的理解。

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

在文件 buildliteBUILD.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 又进一步被什么模块调用？在恒玄的代码配置文件 devicesocbestechnicbes2600BUILD.gn 中使用了，非恒玄的没有调用 //build/lite:product。所以，除了 //build/lite:product，还有其他调用编译产品解决方案代码的地方。

以 vendorgoodixgr5515_sk_iotlink_demo 为例，来了解下什么地方会调用编译产品解决方案代码。产品解决方案根目录下有文件 vendorgoodixgr5515_sk_iotlink_demoohos.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 文件，解析子系统和部件信息，生成到 outgr5515_skgr5515_sk_iotlink_demobuild_configsparts_infosubsystem_parts.json 文件中，片段如下。这些解析出来的子系统和部件信息，编译构建构建 hb 会组织进行编译构建。

 

  "product_gr5515_sk_iotlink_demo": [
    "product_gr5515_sk_iotlink_demo"
  ],

 

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

在文件 kernelliteos_mBUILD.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、内核代码如何被调用编译的

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

在生成的文件 outv200zrdisplay_demobuild_configskernelliteos_mBUILD.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

在文件 kernelliteos_mBUILD.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" ]
        }
    }
    }

 

审核编辑 黄宇