??想了解更多關于開源的內容，請訪問：??
??51CTO 開源基礎軟件社區??
??https://ost.51cto.com??
前言
大家好，前段時間學業比較忙，已經有挺長一段時間沒有更新博客了，這段時間開始實習生活，會將更多的精力投入到開源鴻蒙的研究學習中，會盡量多更新實習期間的所學所得，分享給大家，一起學習進步！
本篇文章要分享的是OpenHarmony的一個編譯構建實踐，隨著版本更新，OpenHarmony的編譯方式也會出現一些小變化，這次將以OpenHarmony-3.2-Beta版本為例，使用九聯UnionPi-Tiger開發板，介紹下子系統，部件，模塊的配置規則以及編譯構建實踐。
概述
OpenHarmony整體遵從分層設計，從下向上依次為：內核層、系統服務層、框架層和應用層。系統功能按照“系統 > 子系統 > 部件”逐級展開，在多設備部署場景下，支持根據實際需求裁剪某些非必要的子系統或部件。
- 子系統：子系統是一個邏輯概念，它具體由對應的部件構成。
- 部件：對子系統的進一步拆分，可復用的軟件單元，它包含源碼、配置文件、資源文件和編譯腳本；能獨立構建，以二進制方式集成，具備獨立驗證能力的二進制單元。需要注意的是下文中的芯片解決方案本質是一種特殊的部件。
- 模塊：模塊就是編譯子系統的一個編譯目標，部件也可以是編譯目標。
- 特性（feature）：特性是部件用于體現不同產品之間的差異。
上圖編譯子系統的各部分關系，主要體現為：
- 子系統是某個路徑下所有部件的集合，一個部件只能屬于一個子系統。
- 部件是模塊的集合，一個模塊只能歸屬于一個部件。
- 通過產品配置文件配置一個產品包含的部件列表，部件不同的產品配置可以復用。
- 部件可以在不同的產品中實現有差異，通過變體或者特性feature實現。
- 模塊就是編譯子系統的一個編譯目標，部件也可以是編譯目標。
環境
- OpenHarmony-3.2-Beta5
- 九聯UnionPi-Tiger開發板
- USB_Burning_Tool燒錄工具
- 串口調試助手
參考
??編譯構建指導??NAPI框架生成代碼集成到OpenHarmony的方法
一、子系統配置
通過build倉下的subsystem\_config.json可以查看所有子系統的配置規則。子系統的配置規則主要是在build/subsystem_config.json中指定子系統的路徑和子系統名稱。
注意：在已有子系統的目錄下再創建子系統會導致重復獲取到部件配置文件而導致報錯。（血淚教訓）
二、部件配置
bundle.json與ohos.build
配置完子系統后，系統會自動識別該目錄下的所有部件配置文件，新增部件的方式有兩種，分別為增加ohos.build文件方式和增加bundle.json文件方式，各自的配置方法如下。
1、ohos.build配置格式
{
"subsystem": "mysubsys" # mysubsys所屬子系統的名字
"parts": {
"ohos_build_test": { # ohos_build_test為部件名稱
"module_list": [
"http://mysubsys/ohos_build_test:mygroup" # 部件編譯入口
]
"test_list": []
}
}
}2、bundle.json配置格式
{
"name": "@ohos/sensor_lite", # HPM部件英文名稱，格式"@組織/部件名稱"
"description": "Sensor services", # 部件功能一句話描述
"version": "3.1", # 版本號，版本號與OpenHarmony版本號一致
"license": "MIT", # 部件License
"publishAs": "code-segment", # HPM包的發布方式，當前默認都為code-segment
"segment": {
"destPath": ""
}, # 發布類型為code-segment時為必填項，定義發布類型code-segment的代碼還原路徑（源碼路徑）
"dirs": {"base/sensors/sensor_lite"}, # HPM包的目錄結構，字段必填內容可以留空
"scripts": {}, # HPM包定義需要執行的腳本，字段必填，值非必填
"licensePath": "COPYING",
"readmePath": {
"en": "README.rst"
},
"component": { # 部件屬性
"name": "sensor_lite", # 部件名稱
"subsystem": "", # 部件所屬子系統
"syscap": [], # 部件為應用提供的系統能力
"features": [], # 部件對外的可配置特性列表，一般與build中的sub_component對應，可供產品配置
"adapted_system_type": [], # 輕量(mini)小型(small)和標準(standard)，可以是多個
"rom": "92KB", # 部件ROM值
"ram": "~200KB", # 部件RAM估值
"deps": {
"components": [ # 部件依賴的其他部件
"samgr_lite",
"ipc_lite"
],
"third_party": [ # 部件依賴的三方開源軟件
"bounds_checking_function"
]
}
"build": { # 編譯相關配置
"sub_component": [
""//base/sensors/sensor_lite/services:sensor_service"", # 部件編譯入口
], # 部件編譯入口，模塊在此處配置
"inner_kits": [], # 部件間接口
"test": [] # 部件測試用例編譯入口
}
}
}- 部件配置中需要配置部件的名稱、源碼路徑、功能簡介、是否必選、編譯目標、RAM、ROM、編譯輸出、已適配的內核、可配置的特性和依賴等屬性定義。
使用場景對比
兩種集成方式使用場景說明：
ohos.build方式集成：適合3.0前版本使用。
bundle.json方式集成：兼容ohos.build方式，但3.1及以后版本建議使用此種方式集成，更好兼容HPM。
三. 模塊配置
具體參考??模塊配置規則??。
編譯子系統通過模塊、部件和產品三層配置來實現編譯和打包。模塊就是編譯子系統的一個目標，包括（動態庫、靜態庫、配置文件、預編譯模塊等）。模塊要定義屬于哪個部件，一個模塊只能歸屬于一個部件。OpenHarmony使用定制化的Gn模板來配置模塊規則。
以下是常用的模塊配置規則：
# C/C++模板
ohos_shared_library
ohos_static_library
ohos_executable
ohos_source_set
# 預編譯模板：
ohos_prebuilt_executable
ohos_prebuilt_shared_library
ohos_prebuilt_static_library
#hap模板
ohos_hap
ohos_app_scope
ohos_js_assets
ohos_resources
#其他常用模板
#配置文件
ohos_prebuilt_etc
#sa配置
ohos_sa_profile
ohos開頭的模板對應的.gni文件路徑在：openharmony/build/templates/cxx/cxx.gni。
這里以ohos_executable為例，配置規則如下：
import("http://build/ohos.gni")
ohos_executable("helloworld") {
configs = [] # 配置
part_name = [string] # 部件名稱
subsystem_name = [string] # 子系統名稱
deps = [] # 部件內模塊依賴
external_deps = [ # 跨部件模塊依賴定義，
"part_name:module_name", # 定義格式為 "部件名:模塊名稱"
] # 這里依賴的模塊必須是依賴的部件聲明在inner_kits中的模塊
ohos_test = []
test_output_dir = []
# Sanitizer配置，每項都是可選的，默認為false/空
sanitize = {
# 各個Sanitizer開關
cfi = [boolean] # 控制流完整性檢測
cfi_cross_dso = [boolean] # 開啟跨so調用的控制流完整性檢測
integer_overflow = [boolean] # 整數溢出檢測
boundary_sanitize = [boolean] # 邊界檢測
ubsan = [boolean] # 部分ubsan選項
all_ubsan = [boolean] # 全量ubsan選項
...
debug = [boolean] # 調測模式
blocklist = [string] # 屏蔽名單路徑
}
testonly = [boolean]
license_as_sources = []
license_file = [] # 后綴名是.txt的文件
remove_configs = []
static_link = []
install_images = []
module_install_dir = [] # 模塊安裝路徑，從system/，vendor/后開始指定
relative_install_dir = []
symlink_target_name = []
output_dir = [directory] # 存放輸出文件的目錄
install_enable = [boolean]
version_script = []
use_exceptions = []
}四、編譯構建全實踐
1、添加子系統mysubsys
在子系統下新建一個屬于自己的名為mysubsys子系統，并在源碼下建立相應的mysubsys目錄。
"mysubsys": {
"path": "mysubsys",
"name": "mysubsys"
}在mysubsys新建兩個部件，分別用來測試bundle.json以及ohos.build配置部件的實現結果。注意ohos.build或者bundle.json文件均在對應子系統所在文件夾下，BUILD.gn文件位置可以根據需要指定，整體目錄結構如下：
mysubsys
├── bundle_json_test
│ ├── BUILD.gn
│ ├── bundle.json
│ └── test
│ ├── BUILD.gn
│ └── test.c
└── ohos_build_test
├── BUILD.gn
├── ohos.build
└── test
├── BUILD.gn
└── test.c
2、為子系統配置部件及模塊
（1）添加ohos.build測試部件及模塊
mysubsys下新建一個ohos.build文件，根據ohos.build配置規則進行配置。同目錄下建立BUILD.gn編譯腳本，用于指定部件下模塊編譯入口，然后新建文件夾test作為測試模塊，里面在新建test.c源文件以及BUILD.gn文件，生成可執行文件安裝到開發板bin目錄下，可執行文件名為mysubsys_test_ohos。編譯構建關系如下圖所示：
用于測試的源文件test.c:
#include "stdio.h"
int main()
{
printf("test mysubsys for ohos.build\r\n");
return 0;
}
（2）添加bundle.json測試部件及模塊
mysubsys下新建一個bundle.json文件，根據obundle.json配置規則進行配置。同目錄下建立BUILD.gn編譯腳本，用于指定部件下模塊編譯入口，然后新建文件夾test作為測試模塊，里面在新建test.c源文件以及BUILD.gn文件，生成可執行文件安裝到開發板bin目錄下,可執行文件名為mysubsys_test_bundle。編譯構建關系如下圖所示：
#include "stdio.h"
int main()
{
printf("test mysubsys for bundle.json\r\n");
return 0;
}
上述兩個實例可以直接在"module_list"或者"sub_component"里面直接將編譯入口設置為你的模塊目標（動態庫、靜態庫、配置文件、預編譯模塊等），不過在學習過程中，發現OpenHarmony源碼里面關于部件模塊的寫法（例如third_party），發現很多都會額外寫一個BUILD.gn來新建一個group，用來包含一個或多個目標的虛節點，這里我也習慣這么寫了。
3、產品配置中添加相應子系統及部件
在vendor/unionman/unionpi_tiger/config.json文件添加如下配置：
4、編譯燒錄運行
操作流程具體參考https://gitee.com/openharmony/device_board_unionman/blob/master/unionpi_tiger/README_zh.md，這里不多贅述。
./build.sh --product-name unionpi_tiger #編譯
./device/board/unionman/unionpi_tiger/common/tools/packer-unionpi.sh # 鏡像打包
電腦連接開發板debug口，打開串口工具，生成的可執行文件mysubsys_test_ohos，mysubsys_test_bundle都可以在bin目錄找到，在終端執行執行：
mysubsys_test_ohos
mysubsys_test_bundle
結果：
文章相關附件可以點擊下面的原文鏈接前往下載：
?https://ost.51cto.com/resource/2564。??
??想了解更多關于開源的內容，請訪問：??
??51CTO 開源基礎軟件社區??
??https://ost.51cto.com??
