目录
- 1. 关于工程本身
- 2. ohos_bundles
- 3.工程的目录结构
更新记录：
1. 关于工程本身
老规矩，从0开始。
在Linux环境下的DevEco IDE下创建新工程“Hi3861_Wifiiot”，设置如下图，点击“创建”，会在Projs目录生成默认的工程。
全部文件都查看一遍，看上去只有 bundle.json 有点有用信息：
{
"name": "default",
"version": "1.0.0",
"description": "This is a default bundle",
"publishAs": "source",
"scripts": {
"build": "make"
},
"dirs": {
"headers": [
"headers/*.h"
],
"src": [
"src/*.c"
],
".": "Makefile"
},
........[省略]
"dependencies": {},
"devDependencies": {}
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
按照 README.md的提示，执行“hpm build”，生成了 bin/hello 和 bundle-lock.json，执行“./bin/hello”打印“Hello world”，而bundle-lock.json则是空的。
至此，看上去工程跟鸿蒙系统/工程没多少关系，其他文件都可以删掉，唯独“bundle.json”不能删除，要是删除这个文件的话，下面这步就会 install 失败。
在DevEco IDE的HPM标签下找到“@ohos/wifi_iot”，选择“Install to project”/“Hi3861_Wifiiot”。
安装完成后，就在Hi3861_Wifiiot目录下得到了
看上去很干净的目录，暂不用IDE一键编译，先试试命令行下的“hpm build”
lkz@ubuntu:~/Work/Projs/Hi3861_Wifiiot$ hpm build
[WARN] - The license of @ohos/gn is gn LICENSE. Notice open-source risks.
[WARN] - The license of @ohos/gcc_riscv32 is GPL V2. Notice open-source risks.
[WARN] - The license of @ohos/wifi_iot is NA. Notice open-source risks.
Building: default
make: *** No targets specified and no makefile found. Stop. //可能是我删掉了makefile的缘故
Build error: Worker stopped with exit code 2
Check error details by "/home/lkz/.hpm/log/debug/debug.2021-04-24-15-40-57.log"
lkz@ubuntu:~/Work/Projs/Hi3861_Wifiiot$ ln -s build/lite/build.py build.py
lkz@ubuntu:~/Work/Projs/Hi3861_Wifiiot$ python build.py wifiiot
[197/197] STAMP obj/vendor/hisi/hi3861/hi3861/run_wifiiot_scons.stamp
ohos wifiiot build success!
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
out目录下也有正常的输出。
2. ohos_bundles
Hi3861_Wifiiot项目下，很明显比鸿蒙系统完整代码的目录多了一个ohos_bundles文件夹和三个json文件，我也注意到在上一步的“Install to project”/“Hi3861_Wifiiot”时，工程目录下最先生成ohos_bundles目录。
下面分别看看三个json文件和ohos_bundles目录都有什么东西。
bundle.json
看上去比“Install to project”前，多了一点东西：
"base": {
"name": "@ohos/wifi_iot",
"version": "^1.0.3"
},
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
bundle-lock.json
看上去列出了本工程所有的组件共计24个压缩包的下载地址和checksum，最后一个"@ohos/wifi_iot"还列出了这个组件依赖于上面的所有组件。
product.template.json
"ohos_version": "OpenHarmony 1.0",
"board": "hi3861v100",
"kernel": "liteos_riscv",
"compiler": "gcc",
"subsystem": [],
"vendor_adapter_dir": "//vendor/hisi/hi3861/hi3861_adapter",
"third_party_dir": "//vendor/hisi/hi3861/hi3861/third_party",
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
很明显的信息。不过为什么要特别列出 "vendor_adapter_dir"?有什么特别的作用吗?还不清楚。
ohos_bundles/@ohos/目录
很明显这是全工程24个组件的独立目录。
随便进入build看一下，熟悉的就不说了，看一下bundle.json：
{
"name": "@ohos/build",
"version": "1.0.1",
"publishAs": "code-segment",
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
"description": "编译构建提供了一个在GN与ninja基础上的编译构建框架。
支持以下功能：构建不同芯片平台的产品。如：Hi3518EV300平台的ipcamera产品，
Hi3516DV300平台的ipcamera产品，Hi3861平台的wifi模组产品。
构建HPM包管理配置生成的自定义产品。",
"scripts": {
"install": "DEST_PATH=${DEP_BUNDLE_BASE}/build &&mkdir -p $DEST_PATH && cp -r ./* $DEST_PATH"
},
"keywords": [
"build"
],
"license": "Apache V2",
"repository": "",
"homepage": "",
"tags": [
"build"
],
"ohos": {
"os": "1.0.0",
"kernel": "liteos-a,liteos-m",
"board": "hi3516,hi3518,hi3861"
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
看上去都是很直白的，就“scripts”这个，看上去就是要执行脚本命令。
DEP_BUNDLE_BASE应该是部署bundle的base目录，也就是项目Hi3861_Wifiiot目录本身。
在Hi3861_Wifiiot/build目录下递归创建子目录，把当前目录下的所有东西全部递归拷贝到Hi3861_Wifiiot/build目录下。
所以Hi3861_Wifiiot/build目录就是 Hi3861_Wifiiot/ohos_bundles/@ohos/build 目录的拷贝。
类似的，其他组件基本上也都是这么个情况，至于它们分别拷贝到代码根目录下的什么地方，请自己去仔细查看bundle.json进行梳理。
不过三个组件有点例外：gcc_riscv32、gn、ninja。这三个是属于构建编译系统的，他们的bundle.json的共同点都是去执行scripts目录下的install.sh脚本，先去仓库地址下载压缩包，然后解压到同目录下。
前面提到“@ohos/wifi_iot”是依赖于其余23个组件的，就必须要仔细看一下它的bundle.json，果然：
"scripts": {
"dist": "export PATH=$PATH:${DEP_OHOS_gcc_riscv32}/gcc_riscv32/bin: ${DEP_OHOS_gn}/gn:${DEP_OHOS_ninja}/ninja
&& hpm run parse && hpm run select && hpm run connect && hpm run compile",
"parse": "node ./dist_scripts/parse_platform_hpm.js hi3861v100_liteos_riscv",
"select": "node ./dist_scripts/select_product.js",
"connect": "node ./dist_scripts/connect_subsystem.js wifiiot",
"compile": "ln -sf ${DEP_BUNDLE_BASE}/build/lite/build.py ${DEP_BUNDLE_BASE}/build.py &&
cd ${DEP_BUNDLE_BASE} &&python ${DEP_BUNDLE_BASE}/build.py wifiiot",
"install": "cp product.template.json ${DEP_BUNDLE_BASE}",
"eco": "echo $target"
},
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
先把三个构建编译工具所在目录的bin添加到环境变量中，再执行parse、select、connect、compile命令，前三个命令的脚本都在当前目录的dist_scripts内，而compile命令则是在代码根目录下先创建build.py的软链接，再切换到根目录下执行python build.py wifiiot开始构建和编译。根据《鸿蒙系统的编译流程及分析》一文中提到的Gn+Ninja的工作原理和步骤，会先去把它所依赖的23个组件都编译好，最终生成用于烧录开发板的bin文件。
这就很明白了。
3.工程的目录结构
我在《鸿蒙系统的编译流程及分析》(Link: https://harmonyos.51cto.com/posts/4070)一文中大致整理了一下鸿蒙系统的build、out目录结构，整个鸿蒙系统的目录结构太复杂了，我的理解还不到位，没法整理出来。不过这个Hi3861_Wifiiot工程，是经过hpm裁剪了的，总共才24个组件，内核也简单了很多，再加上这段时间我调试Hi3861的开发板，对工程内文件/代码有了一点点了解，也到了做一次整理的时候了，所以我又整理出了下面这个表格。粗浅的理解，希望能对大家有所帮助，更详细的信息，还是需要各位自己去看README和读代码，能亲自在开发板上调试效果会更好。
