[本文正在參加星光計劃3.0–夏日挑戰賽]
一、前言
本文将簡單介紹一下輕量和小型系統使用到的編譯工具，詳細講解新增子產品後編譯依賴的三種配置方式。
<br>
二、gn和ninja
輕量級和小型系統是一個基于gn和ninja的建構系統，以支援OpenHarmony元件化開發為目标，支援元件拼裝産品并編譯，獨立建構晶片解決方案源碼，獨立建構單個元件。新增元件開發完成後，需要基于gn文法配置建構資訊，并儲存在BUILD.gn檔案中。大家可以借助唐老師的這篇文章進一步了解鴻蒙中的Gn和Ninja:淺析鴻蒙的Gn與Ninja
<br>
三、開發準備
尚未安裝開發環境的可以參考這篇文章step by step進行配置：
DevEco Device Tool一站式內建開發環境搭建
從源碼擷取，編譯，燒錄到序列槽調試的一站式內建開發，可以參考這篇：
DevEco Device Tool裝置開發全流程概述
做完以上準備後，相信大家已經能輕松完成工程編譯、代碼燒錄等工作并跑通整個流程了。以上工作準備完成後就可以進入到開發環節了。
其實，功能開發一般是大家比較熟悉地，除了新增接口的使用外，技術上沒有太多難度，很多時候都是在移植原有功能。功能開發完成後，怎麼內建到系統裡面，應該是大家比較關心的問題，這也是OpenHarmony裝置開發差別于其他嵌入式開發不同的地方。
<br>
四、編譯依賴的三種配置方式
首先，我們先來了解編譯和編譯依賴。簡單來說，編譯時被依賴的子產品或代碼都會參與到編譯中來，OpenHarmony中引入依賴有以下三種方式：
- 産品配置config.json中增加元件依賴。
- 已有子產品BUILD.gn中deps配置元件依賴。
- 已有子產品中增加源碼路徑，通過檔案引入依賴。
接下來我們需要先增加一個元件示範元件依賴的配置和檔案依賴的配置
在applications/sample/wifi-iot/app目錄下增加my_first_demo元件，配置如下圖：
demo01.c代碼如下
#include <stdio.h>
#include "ohos_init.h"
#include "ohos_types.h"
void demo(void)
{
printf("開源項目 OpenHarmony\n是每個人的OpenHarmony\n");
}
SYS_RUN(demo);
顯然，C檔案是三種編譯依賴方式都需要的，關系到功能開發。
接下來，就讓我們一個個來剖析三種編譯依賴方式吧。
1.産品配置config.json中增加元件依賴
首先，我們需要編寫用于将業務建構成靜态庫的 BUILD.gn 檔案。demo001即為靜态庫名稱（後面會用到）：
static_library("demo001"){
sources = [
"demo01.c"
]
include_dirs = [
"//utils/native/lite/include"
]
}
BUILD.gn是建構配置檔案，定義了建構目标，是前兩個元件依賴方式必須要有的。于是元件目錄變成了這樣
從裝置開發的角度來看，我們增加的功能一般屬于應用層，一般會配置在應用子系統中資訊儲存在applications.json中，如下圖左半部分所示。為了在建産品的時候能夠形成依賴把my_first_demo元件一起編譯進來，我們需要在config.json中配置子系統依賴，加上下圖藍色圈起來的資訊。
注意看上圖的檔案路徑和指向對應關系。
上篇文章我們介紹過config.json是産品解決方案的建構入口，産品解決方案需要的元件都會參與到編譯過程。是以在config.json中配置子系統群組件資訊可以促使my_first_demo工程參與到編譯過程中，并打包進固件。
但是，我們每次建立工程改代碼都要跑到config.json中去進行修改，而config.json上還不能直接修改，得一層層檔案打開去找到application.json找到對應的元件後修改目标檔案位置，光是看上圖的箭頭和檔案目錄都應該知道這個過程有點麻煩了吧
其實，有一些教程提供了更簡便的方案：
例如，在連老師的《OpenHarmony裝置開發入門》書中的HelloWorld例程就是在app子產品BUILD.gn檔案中進行編譯依賴配置，在features字段中增加索引，使目标子產品參與編譯。
::: hljs-center
圖源《OpenHarmony裝置開發第一版》
:::
若按相對路徑的格式寫就是這樣的：
同時，不要忘記删除前面那種方法中藍字圈起來的部分呦！
此時一張非常順滑的依賴指向圖就可以整理出來了
當我們了解這個過程後，再寫類似的程式就可以在子產品app的BUILD.gn中加上短短的一行“元件名：靜态庫名稱”即可了，是不是輕松很多？
其實兩種方法的意思是一樣的，隻是一個層級的問題，類似于我在上層已經指明了，下層就不用再詳細指路了。
<br>
2.已有子產品BUILD.gn中deps配置元件依賴
這種方式需要在現有參與編譯的子產品中配置deps依賴。這裡以在hal_token_static中增加my_first_demo為例，被依賴的子產品my_first_demo會一起參與編譯，并打包到最終的固件中。
具體步驟為：将之前在app子產品BUILD.gn中寫的“my_first_demo:demo001”注釋掉，右鍵單擊my_first_demo檔案夾複制相對路徑，然後打開
vendor/hisilicon/hispark_pegasus/hals/utils/token/BUILD.gn添加deps：
static_library("hal_token_static") {
sources = [ "hal_token.c" ]
include_dirs = [
"//base/startup/syspara_lite/hals",
"//utils/native/lite/include",
]
deps = [
"//applications/sample/wifi-iot/app/my_first_demo:demo001" # 添加此行
]
}
然後編譯，燒錄，檢視螢幕可以得到demo.c中列印的語句：
當控制變量删去deps配置時将不會有該語句列印出。
這種方式是一種隐式依賴，不難看出，此依賴方式必須依賴已編譯的子產品才能執行，是以隻有兩子產品相關度比較高，直接依賴了my_first_demo時才使用這種方式，否則還是推薦使用前面所說的方式。
<br>
3.已有子產品中增加源碼路徑，通過檔案引入依賴
最後一種是檔案依賴，是最簡單的一種方式，隻需要在現有的子產品中增加源檔案即可一起參與編譯。
再次以在hal_token_static子產品中進行操作為例：
static_library("hal_token_static") {
sources = [
"hal_token.c",
"//applications/sample/wifi-iot/app/my_first_demo/demo01.c"
]
include_dirs = [
"//base/startup/syspara_lite/hals",
"//utils/native/lite/include",
]
deps = [
#"//applications/sample/wifi-iot/app/my_first_demo:demo001"
]
}
此時，删除了my_first_demo目錄下的BUILD.gn檔案（可有可無，反正不會用到）後依然成功列印出了目智語句！
這種方式，一般用于耦合關系比較大的功能，互相調用較多或者接口依賴較強。此時可以把檔案放在同一個子產品中一起編譯，減少配置的複雜度
五、後記
參考文檔及教程：
OpenHarmony基礎
《OpenHarmony裝置開發入門》
不知道大家看完本篇文章，對于編譯依賴有沒有更深層次的了解呢？
這三種依賴方式各有優劣，大家不妨每一個方法都去試驗一下。我們需要在以後的開發過程中多多體會，充分利用好OpenHarmony的子產品化、可裁剪的優勢，根據需要進行配置。
這裡再提一嘴，我不允許有人還沒用DevEco Device Tool搞南向開發！簡直太好用了！不信你看這篇文章然後自己體驗一下如果不是我前些天改用了這個開發環境的話，反複跳轉工具編譯燒錄開序列槽等等，得浪費多少時間啊
總之，希望本文能幫到大家，如果有沒有考慮到的、不對的地方，歡迎交流探讨~
附件連結：https://ost.51cto.com/resource/2229