openharmony的编译构建系统
1.概念
一个基于gn和ninja的、以支持OpenHarmony组件化开发为目标的现代化编译构建系统。
ninja:一个专注于速度的小型编译构建系统. gn:一种现代化的跨平台的编辑构建工具,Generate ninja 的缩写，用于产生ninja文件. hb:OpenHarmony的命令行工具，用来执行编译命令.
2.基本功能
- 独立构建单个组件
- 独立构建芯片解决方案厂商源码（开发板）
- 支持按组件拼装产品并编译
3.核心理念
- 子系统 一个逻辑概念，由一个或多个具体组件构成。 OpenHarmony系统功能按"系统">"子系统">"组件"逐级展开，支持裁剪子系统或组件。
- 组件 可复用、可配置、可裁剪的系统最小功能单元。 APP也是组件的一种。 组件目录独立，可并行开发、单独编译、单独测试。
最顶层的openharmony是一个操作系统，他由多个系统或者叫做子系统集构成，而每个系统又是由多个子系统构成，每个子系统又包括了多个组件，子系统和组件，都是可以被裁剪的。 （裁剪，就是去掉它不要，在最终的构建中不包括他）
下面我们来看一下build/lite下的目录结构。 打开vscode，从虚拟机中获取1.1.3版本的源码。获取源码的步骤可以看我上一篇博客：https://ost.51cto.com/posts/25292 
├── components-------//组件描述文件 ├── config-------------//编译相关的配置项 │ ├── component------//组件相关的模板定义 │ ├── kernel---------//内核的编译配置参数 │ └── subsystem------//子系统模版 ├── figures------------//readme中的图片 ├── hb-----------------//hb pip安装包源码 ├── make_rootfs--------//文件系统镜像制作脚本 ├── ndk----------------//Native API相关编译脚本与配置参数 ├── platform-----------//ld脚本 ├── testfwk------------//测试编译框架 ├── toolchain----------//编译工具链配置，包括编译器路径、编译选项、链接选项等
4.编译构建流程
编译构建流程主要分为两步：设置（hb set） 和 编译（hb build） 
- hb set用来设置Openharmony源码目录和要编译的目标。 比如在如下图中，我们选择编译的产品是wifiiot_hispark_pegasus
- hb build 编译开发板、产品或组件。 主要过程：
- 读取编译配置:根据产品选择的开发板，读取开发板config.gni文件内容，主要包括编译工具链、编译链接命令和选项等。
- 调用gn:调用"gn gen",读取产品配置，生成产品解决方案out目录和ninja文件。
- 调用ninja: 调用"ninja -C out/board/product"启动编译。
- 系统镜像打包:将组件编译产物打包，设置文件属性和权限，制作文件系统镜像。
注意： 在轻量系统中，组件作为一个单独的模块，不能够直接烧录到开发板中，他必须加入到一个产品或者是一个开发板方案中，作为一个完整的固件之中的一个功能点。
编译构建系统的配置规则
概述：为了实现组件、芯片解决方案、产品解决方案与OpenHarmony是解耦的、可插拔(可裁剪)的，组件、芯片解决方案和产品解决方案的路径、目录树和配置需遵循一定的规则。
何为目录树呢： 一般情况下我们会为一个组件建立一个单独的目录 
组件源码路径不能随意乱来，要分为三个层级：{领域}/{子系统}/{组件} 领域：子系统集 
确定好组件目录的具体位置后，相当于组件就有了一个家，而这个家需要简单的装修一下，划分一下功能区 就像我们的家里有客厅，厨房，卧室等等。组件的家也需要有一定的结构，这个结构就是目录树。
下面我们来看一个例子： 源码分析: loT外围设备控制组件 这个组件的源码路径为：base/iot hardware/peripheral 
打开vscode，找到这个路径。显示如下： 
正是符合上图的源码目录树规则：
- kits目录下存放了应用接口
- 扩展名是.h的文件正是接口头文件，使用具体的接口时，要去include他们
- BUILD.gn是组件编译脚本
至此，我们对Openharmony编译构建系统的理解已经迈进了一大步。
组件的定义
作为一个组件，必须要注册到一个子系统中，Openharmony才会意识到你的存在。 定义的位置：build/lite/components/<对应子系统>.json 打开vscode，找到这个路径，显示如下： 
可以看到，这里存放了很多json文件，而每一个json文件都对应了一个子系统。 在定义子系统的json文件时，我们要把自己的基本情况告诉这个子系统。 注意：新增组件时需要在对应子系统json文件中添加相应的组件定义。产品所配置的组件必须在某个子系统中被定义过，否则会校验失败。 下面我们来看一下需要定义的内容有哪些。
- 名称
- 功能简介
- 是否必选
- 源码路径
- 编译目标
- RAM
- ROM
- 编译输出
- 已适配的内核、
- 可配置的特性和依赖等。 我们继续来看一个例子。还是刚刚的IoT外围设备控制组件 在build/lite/components/iot_hardware.json中
组件的编译目标（编译入口）
其实就是组件定义中的targets参数。 格式： "targets":["路径:目标"] -路径：采用绝对路径表示，以"//"开头，从源码根目录开始。 -目标：由"路径/BUILD.gn"定义
举个例子： 
"targets"：["//base/iot_hardware/peripheral:iothardware"]
- 路径： //base/iot_hardware/peripheral
- 目标： iothardware Openharmony会去这个路径下找到BUILD.gn文件，在这个文件中，找到iothardware这个目标部分，按这部分的要求进行编译。
下面我们就来看一下BUILD.gn文件如何编写
组件的编译脚本
- 类型 -静态库 (.a) ： static_library -动态库 (.so) ： shared_library -可执行文件 (bin 文件 ) ： executable -组： group
- 目标：编译目标名称（官方建议与组件一致）
- sources ：源文件列表
- include_dirs ： include 目录列表
举个例子：IoT外围设备控制组件
先从组件定义的json文件中找到编译目标： build\lite\components\iot_hardware.json -> targets 
再根据targets中的路径找到BUILD.gn编译脚本：base\iot_hardware\peripheral\BUILD.gn 
注意：此脚本负责整个 IoT 专有硬件服务子系统的编译。通过 subsystem_components( 子系统组件 ) 方式指定 IoT 外围设备控制组件，指向下级编译 脚本。 "$ohos_vendor_adapter_dir" 表示 "device\hisilicon\hispark_pegasus
hi3861_adapter" 目录。 我们再跟踪到 device\hisilicon\hispark_pegasus\hi3861_adapter\hals\iot_hardware\wifiiot_lite
BUILD.gn，如下正是组件的编译脚本内容。 
下面我们再看一个例子。 kv_store 组件（键值存储） 他位于 build\lite\components\utils.json 中的第 1 个组件
编译脚本： utils\native\lite\kv_store\BUILD.gn 
注意：此脚本通过 lite_component( 组件 ) 的 features( 模块 ) 方式 指定 utils_kv_store 模块，指向下级编译脚本。 我们跟踪到utils\native\lite\kv_store\src\BUILD.gn,如下正是组件编译脚本。 
到这，我们编译构建系统的配置规则也就学习完了，相信同学们会对Openharmony的构建编译系统有更深一步的理解。 下面附上子系统的构建模型。 
以上内容如有不足之处，欢迎大家指出。小编将会在下一篇博客中讲解如何新增组件和轻量系统的数据持久化。
本文作者：sunqihan