背景
最近搞一个sensor接入openharmony的事情，在分析源码中的加速度计驱动相关源码时，发现不紧有BUILD.gn文件，还有Makefile文件，并且里面都有记录源文件路径。所以很困惑，openharmony是通过gn+ninja编译的还是通过make编译的？
为了搞清楚，所以针对liteos-a系统下的编译过程进行分析，在这里记录一下
入口
通过官方文档看，liteos-a系统编译时用的是官方的hb命令hb set和hb build命令，所以入口肯定是hb工具
查看openharmony源码中build目录下有一个lite/hb目录（hb命令的源码目录，使用python脚本）
编译过程调试
看鸿蒙研究站里面有一篇介绍hb命令的调试方法，通过vscode+python插件调试，参见《v59.xx 鸿蒙内核源码分析(构建工具篇) | 顺瓜摸藤调试鸿蒙构建过程》
说明:
- 主要是创建一个launch.json文件，里面定义调试命令的入口（详细信息可以在网上查询）。为了多次调试效果一样，在调试build命令时，我增加了-f选项，这样每次都会全新编译，如下
{//hb build
"name": "hb build debug",
"type": "python",
"request": "launch",
"program": "./build/lite/hb/__main__.py",
"console": "integratedTerminal",
"args": ["build", "-f"],
"stopOnEntry": true
},
- 在win+虚拟机linux编译系统场景，我没有调试成功，后面搞成功了再补充；这里我是直接在linux环境进行调试，这个依赖于linux本地编译，不要使用docker镜像
hb set
设置好之后就可以开始在vscode上调试
-
选择"hb set"调试目标并按F5，会停在
./build/lite/hb/__main__.py的代码开始处
hb命令调试.png -
在80行打断点并按F5
hb_set_1.png -
按F11可以进入set.py的
exec_command接口
hb_set_2.png -
然后就可以继续后续的调试工作，
hb set命令主要是生成ohos_config.json这个后面编译要使用的配置文件，这里就不详细记录调试的过程了
hb_set_3.png
hb build -f
这个是整个编译的重点，通过调试可以看到最终是调用了gn/ninja/fs_make，如下分析
-
前两步跟
hb set命令一样，第三步会进入build.py的exec_command接口
hb_build_1.png -
这个接口的前面我们先略过，我们先在接口最后的build.build接口处加断点，并按F5
hb_build_2.png -
按F11进入，并在
build_process.py的135行加断点再按F5
hb_build_3.png -
查看cmd_list变量的值有3个（除去内置的）接口，分别是
Build.gn_build、Build.ninja_build、Packer.fs_make
hb_build_4.png
这个就是整体的编译过程了，先调用gn生成ninja文件，再通过ninja进行编译，最后通过fs_make制作镜像
因为内容太多，下面对这三个编译动作先做个整体的介绍，后续再对每一个进行详细分析
gn_build
继续调试，会先进入gn_build接口，看实现就是调用了gn gen命令，如下
查看gn_cmd变量，详细命令为(比较多，经过了整理)：
这个命令之后，就会将工程中所有用到的BUILD.gn文件转换成<module_name>.ninja文件(类似makefile)供后面ninja命令（类似make）调用并进行编译
ninja_build
再继续调试就会进入ninja_build接口，实现以及执行的详细的ninja命令如下
这个命令与make命令类似，但是注重速度（详细信息可以在网上搜索两者区别）；此命令执行即是通过build.ninja/toolchain.ninja/各BUILD.gn转换的.ninja来进行编译，并生成.bin/.so/.a等文件
fs_make
-
fs_make接口会读取在vendor目录下定义好的fs.yml文件，获取到对镜像的配置信息，读取到mksh_rootfs/rootfs/userfs三个fs_cfg信息，如下
hb_build_fs_make1.png -
对于每一个fs_cfg都会调用定义好的6个接口，如下
hb_build_fs_make2.png
编译结束
整个编译OK之后会输出如下图中成功信息
在out目录下就会生成烧录用到的镜像文件，如下图
