配置完畢產品解決方案、芯片開發(fā)板解決方案，就可以執(zhí)行 hb build 進行編譯。但是產品解決方案代碼是如何被調用編譯的？

芯片開發(fā)板解決方案代碼是如何被調用編譯的？內核代碼如何被調用編譯的？解決了這些疑惑，會對 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，片段如下。可以看到，有子系統(tǒng) subsystem 和部件信息 parts。

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

在編譯構建時，會基于 ohos.build 文件，解析子系統(tǒng)和部件信息，生成到 outgr5515_skgr5515_sk_iotlink_demobuild_configsparts_infosubsystem_parts.json 文件中，片段如下。這些解析出來的子系統(tǒng)和部件信息，編譯構建構建 hb 會組織進行編譯構建。

  "product_gr5515_sk_iotlink_demo": [
    "product_gr5515_sk_iotlink_demo"
  ],

2、芯片開發(fā)板解決方案代碼是如何被調用編譯的

在文件 kernelliteos_mBUILD.gn 中定義的名為 modules 構建目標，這個 modules 構建目標依賴芯片開發(fā)板解決方案的代碼。。⑴處判斷芯片和開發(fā)板是否是否進行了文件夾解耦，如果開發(fā)板路徑包含 “/board/”, 說明 soc 和 board 進行了解耦。根據是否解耦，依賴的芯片開發(fā)板的構建配置文件路徑是不同的，見⑵。

  # 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 += [ "http://device/board/$device_company" ]
        deps += [ "http://device/soc/$LOSCFG_SOC_COMPANY" ]
    } else {
        if (HAVE_DEVICE_SDK) {
        deps += [ device_path ]
        }
    }
    }

名為 modules 構建目標又被 libkernel 構建目標、進一步被名為 kernel 的構建目標調用，如下所示。內核的 kernel 構建目標如何被調用，下一小節(jié)分析。

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

group("kernel") {
  deps = [ ":libkernel" ]
}

3、內核代碼如何被調用編譯的

上文分析了產品解決方案、芯片開發(fā)板解決方案如何被調用的。本小節(jié)，追蹤下內核代碼是如何被調用編譯的。

在生成的文件 outv200zrdisplay_demobuild_configskernelliteos_mBUILD.gn 中，會調用名為 kernel、build_kernel_image 的構建目錄。怎么生成的這個文件，需要研究下 hb 的代碼，深入了解下后臺的機制，希望后續(xù)有時間可以繼續(xù)深入一些。

import("http://build/ohos/ohos_kits.gni")
import("http://build/ohos/ohos_part.gni")
import("http://build/ohos/ohos_test.gni")

ohos_part("liteos_m") {
subsystem_name = "kernel"
module_list = [
    "http://kernel/liteos_m:kernel",
    "http://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 文件會依次調用各個子系統(tǒng)和部件的構建目標。

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 = [ "http://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 定義如下。⑴處判斷芯片和開發(fā)板是否是否進行了文件夾解耦，如果開發(fā)板路徑包含 “/board/”, 說明 soc 和 board 進行了解耦。根據是否解耦，依賴的 public 的配置集的位置是不同的，見⑵。在芯片、開發(fā)板代碼目錄中的 BUILD.gn 文件中并沒有發(fā)現 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 += [ "http://device/board/$device_company:public" ]
        configs += [ "http://device/soc/$LOSCFG_SOC_COMPANY:public" ]
    } else {
        if (HAVE_DEVICE_SDK) {
        configs += [ "$device_path:public" ]
        }
    }
    }

審核編輯 黃宇