鸿蒙标准系统3.1的编译构建简单解读

​​想了解更多关于开源的内容，请访问：​​

​​51CTO 开源基础软件社区​​

​​https://ost.51cto.com​​

./build/prebuilts_download.sh该命令主要是在构建之前下载一些依赖的工具包或二进制，见源码同级目录的文件夹OpenHarmony_2.0_canary_prebuilts。

下图是除了进入GN构建之外的脚本的全局构建流程：

子系统配置文件包含以下三个文件，定义了子系统的名称和所在路径。

1. 子系统配置文件：//build/subsystem_config.json，主要包含子系统名称与路径信息。
2. product配置文件：productdefine/common/products/{产品名称}.json，该配置文件主要包含产品名称，产品厂商，产品设备名，产品类型，产品对应子系统路径，产品所包含的部件等信息。
3. device配置文件：productdefine/common/device/{产品设备名称}.json，该配置文件主要包含设备名称，设备厂商，设备的目标os与目标cpu，设备对应子系统路径等信息。
   在preloader阶段以上三个文件会被加载，并通过提取不同字段的信息，归类出多个配置文件。

以上工作主要由脚本build/lite/hb_internal/preloader/preloader.py完成，并将配置文件输出在**out/preloader/{产品名称}**目录下，为loader阶段扫描相应的子系统配置文件做准备，具体对应关系如下图：

鸿蒙的编译构建子系统提供了一个基于Gn和ninja的编译构建框架。根据产品配置，编译生成对应的镜像包。其中编译构建流程为：

1. 使用Gn配置构建目标。
2. Gn运行后会生成ninja文件。
3. 通过运行ninja来执行编译任务。

Preloader阶段结束后，//build/lite/hb_internal/build/build_process.py.gn_build开始触发构建，以产品Hi3516DV300为例，命令和参数如下：

gn gen --args=ohos_build_compiler_specified="clang" ohos_build_compiler_dir="//prebuilts/clang/ohos/linux-x86_64/llvm" product_path="/home/osm/Work/openharmony/openharmony_3.1/code/productdefine/common/products" product_name="Hi3516DV300" device_name="hi3516dv300" target_cpu="arm" target_os="ohos" is_standard_system=true device_path="device/board/hisilicon/hispark_taurus/linux" ohos_kernel_type="linux" common_feature_verify=true ohos_build_type="debug" ohos_build_time="1651857930667" ohos_build_datetime="2022-05-06 03:25:30" ohos_build_enable_ccache=true', '/home/osm/Work/openharmony/openharmony_3.1/code/out/hi3516dv300'

GN的总入口：build/core/gn/BUILD.gn。

GN构建的第一步就是进入Loader阶段，该阶段主要是通过Preloader阶段整合的配置信息加载build configs到out/{产品名称}/build_configs目录，该工作是由脚本//build/loader/load.py完成的：

1、根据out/preloader/{产品名称}/subsystem_config.json文件中的子系统名称和路径信息扫描该路径下的子系统配置文件，同时兼容bundle.json和ohos.build。

2、loading platforms config：跟据out/preloader/{产品名称}/platforms.build加载平台配置信息，生成out/{产品名称}/build_configs/platform_list目录下的文件。

3、根据1中获取的bundle.json/ohos.build，解析出out/{产品名称}/build_configs/{subsystem}/{part}/BUILD.gn、out/{产品名称}/build_configs/parts_info/、out/{产品名称}/build_configs/*.gni以及out/{产品名称}/build_configs/**.json等，以及将编译入口的模板build/loader/build_gn.template拷贝到out/{产品名称}/build_configs/BUILD.gn，从而在out/{产品名称}/build_configs目录下构建出整个工程gn脚本的完整依赖关系。

inner_kits是组件提供其它组件的接口，会被其他组件依赖，因此首先编译该部分。构建的具体targets见out/{产品名称}/build_configs/inner_kits_list.gni

该阶段主要包括版本打包和处理流程，输出目录主要在out/{产品名称}/packages/phone目录下，package的流程如下：

images阶段主要是根据packages阶段生成的system module配置文件制作系统文件和升级镜像，输出目录主要在out/{产品名称}/packages/phone/{image_name}和out/{产品名称}/packages/phone/images目录下，主要流程如下：

以上是GN的配置构建流程，GN命令只是用来生成ninja中间文件，运行ninja才会开始真正的构建任务。以产品Hi3516DV300为例，命令和参数如下：

ninja -w dupbuild=warn -C /home/osm/Work/openharmony/openharmony_3.1/code/out/hi3516dv300 images

该命令执行过程中或结束后才会生成上述流程中所输出的文件或镜像文件。

该阶段主要做一些收尾的工作，内容如下：

统计ccache信息，并在根目录输出ccache.log文件。

备份前一次的build.trace.gz并在文件命名上打上时间戳，生成新的build.trace.gz和sorted_action_duration.txt。

根据生成的out/{产品名称}/build.log，提取出所有的warnnings并统计到out/{产品名称}/packages/warning_list.txt。

根据build/subsystem_config.json统计出C的重复率，并打印到终端。

​​想了解更多关于开源的内容，请访问：​​

​​51CTO 开源基础软件社区​​

​​https://ost.51cto.com​​。