精品国产人成在线_亚洲高清无码在线观看_国产在线视频国产永久2021_国产AV综合第一页一个的一区免费影院黑人_最近中文字幕MV高清在线视频

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

剖析OpenHarmony3.0編譯構建流程

OpenHarmony技術社區(qū) ? 來源:HarmonyOS技術社區(qū) ? 作者:亮子力 ? 2021-12-07 10:54 ? 次閱讀

早就打算研究下 OH3.0 的編譯框架了,最近一直在搞移植,總算有點進展了,抽個空來分析下 3.0 的編譯框架。

大體看了下和 2.0 的差別不是特別大:《OpenHarmony 2.0 Canary編譯構建流程》。

OHOS3.0 的打包鏡像腳本由原來 2.0 的 buildadapteruild_image.sh,全部修改替換為 buildohosimagesuild_image.py,將打包 image 鏡像的部分制作成 build_target。

以前是通過 shell 腳本來調用,現在是通過 gn 和 ninja 來調用。主要文件在 buildohosimages 這個文件夾下。

沒有修改的部分就不說了,有需要的可以看我之前的帖子 這篇主要說下不一樣的地方,看 OH3.0 是如何將編譯好的文件打包成鏡像的。

增加編譯參數

3.0 之后在 builduild_scriptsuild_common.sh 增加了 build_cmd+=" build_target=images"。

這句的意思約等于在執(zhí)行默認編譯命令 ./build.sh --product-name Hi3516DV300 會有個默認的參數 --build-target images。

具體流程是這樣的:

builduild_scriptsuild_common.sh→buildcoregnBUILD.gn→buildohosimagesBUILD.gn
action_with_pydeps("${_platform}_${_image_name}_image"){
script="http://build/ohos/images/build_image.py"
depfile="$target_gen_dir/$target_name.d"
deps=["http://build/ohos/packages:${_platform}_install_modules"]

image_config_file=
"http://build/ohos/images/mkimage/${_image_name}_image_conf.txt"
output_image_file="$current_platform_dir/images/${_image_name}.img"

image_input_path="$current_platform_dir/${_image_name}"
if(_image_name=="userdata"){
image_input_path="$current_platform_dir/data"
}

sources=[
image_config_file,
system_module_info_list,
system_modules_list,
]
outputs=[output_image_file]
args=[
"--depfile",
rebase_path(depfile,root_build_dir),
"--image-name",
_image_name,
"--input-path",
rebase_path(image_input_path,root_build_dir),
"--image-config-file",
rebase_path(image_config_file,root_build_dir),
"--output-image",
rebase_path(output_image_file,root_build_dir),
"--build-image-tools-path",
rebase_path(build_image_tools_path,root_build_dir),
]
if(sparse_image){
args+=["--sparse-image"]
}
}

通常情況下,gn 會使用 action 運行一個腳本來生成一個文件,但是這里使用的是 action_with_pydeps,應該也是內置的目標類型。查看官方手冊是這么說明的:

輸入和文件,將操作讀取(或執(zhí)行)的所有文件列為 inputs:

  • 僅按從屬目標列出輸入是不夠的。它們必須由使用它們的目標直接列出,或者由 depfile 添加。

  • 非系統(tǒng) Python 導入是輸入!對于導入此類模塊的腳本,請使用 action_with_pydeps 來確保將所有依賴的 Python 文件捕獲為輸入。

前面還定義了一個 image_list,然后使用 foreach 執(zhí)行 action_with_pydeps,要生成幾個 img 文件,就執(zhí)行幾次 action_with_pydeps。
image_list=[
"system",
"vendor",
"userdata",
"updater",
]
foreach(_image_name,image_list){......}

調用 python 腳本

既然知道了 img 鏡像是由 buildohosimagesuild_image.py 來創(chuàng)建的,那就來分析下這個 python 腳本。
ifos.path.exists(args.output_image_path):
os.remove(args.output_image_path)#刪除之前生成的鏡像文件夾
ifargs.image_name=='userdata':
_prepare_userdata(args.input_path)#準備好userdata.img需要的文件
ifos.path.isdir(args.input_path):
_make_image(args)
_dep_files=[]
for_root,_,_filesinos.walk(args.input_path):
for_filein_files:
_dep_files.append(os.path.join(_root,_file))
build_utils.write_depfile(args.depfile,
args.output_image_path,
_dep_files,
add_pydeps=False)
===================================================================
def_make_image(args):
ifargs.image_name=='system':
_prepare_root(args.input_path)#準備好system.img需要的文件
elifargs.image_name=='updater':
_prepare_updater(args.input_path)#準備好updater.img需要的文件
image_type="raw"
ifargs.sparse_image:
image_type="sparse"
mk_image_args=[
args.input_path,args.image_config_file,args.output_image_path,
image_type
]
env_path="../../build/ohos/images/mkimage"
ifargs.build_image_tools_path:
env_path='{}:{}'.format(env_path,args.build_image_tools_path)
os.environ['PATH']='{}:{}'.format(env_path,os.environ.get('PATH'))
mkimages.mk_images(mk_image_args)#而真正制作鏡像使用的下面的函數
===================================================================
#buildohosimagesmkimagemkimages.py
defmk_images(args):
......
if"system.img"indevice:
src_dir=build_rootdir(src_dir)
mkfs_tools,mk_configs=load_config(config_file)
mk_configs=src_dir+""+device+""+mk_configs

res=run_cmd(mkfs_tools+""+mk_configs)#制作鏡像命令使用的是mkfs_tools
===================================================================
if"ext4"inmk_configs:
fs_type="ext4"
mkfs_tools="mkextimage.py"#而mkfs_tools根據文件系統(tǒng)類型,分別調用對應的python腳本
elif"f2fs"inmk_configs:
mkfs_tools="mkf2fsimage.py"
fs_type="f2fs"
===================================================================
#buildohosimagesmkimagemkextimage.py#制作ext4文件系統(tǒng)
defbuild_run_mke2fs(args):
.....
blocks=int(int(args.fs_size)/BLOCKSIZE)
mke2fs_cmd+=("mke2fs"+str(mke2fs_opts)+"-t"+FS_TYPE+"-b"
+str(BLOCKSIZE)+""+args.device+""+str(blocks))
res=run_cmd(mke2fs_cmd)# mke2fs:制作文件系統(tǒng)
===================================================================
defbuild_run_e2fsdroid(args):
......
e2fsdroid_cmd+=("e2fsdroid"+e2fsdroid_opts+"-f"+
args.src_dir+"-a"+args.mount_point+
""+args.device)
res=run_cmd(e2fsdroid_cmd)# e2fsdroid:制作鏡像文件

無論前面執(zhí)行了什么操作,最終都是為了執(zhí)行 mke2fs、e2fsdroid。

關于這兩個命令:

  • mke2fs:Linux 下的命令,用于建立 ext 文件系統(tǒng)。

  • e2fsdroid:來自三方庫,third_partye2fsprogs。

詳情可以參考:

http://e2fsprogs.sourceforge.net
編輯:jq
聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • Linux
    +關注

    關注

    87

    文章

    11227

    瀏覽量

    208925
  • 編譯
    +關注

    關注

    0

    文章

    654

    瀏覽量

    32806
  • OpenHarmony
    +關注

    關注

    25

    文章

    3660

    瀏覽量

    16152

原文標題:OpenHarmony3.0編譯構建流程!

文章出處:【微信號:gh_834c4b3d87fe,微信公眾號:OpenHarmony技術社區(qū)】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    鴻蒙OpenHarmony南向/北向快速開發(fā)教程-迅為RK3568開發(fā)板

    源碼 P3_初次編譯OpenHarmony源碼 P4_OpenHarmony鏡像簡介以及燒寫工具配置 P5_優(yōu)化開發(fā)流程-搭建windows開發(fā)環(huán)境 P6_優(yōu)化開發(fā)
    發(fā)表于 07-23 10:44

    AI編譯器技術剖析

    隨著人工智能技術的飛速發(fā)展,AI編譯器作為一種新興的編譯技術逐漸進入人們的視野。AI編譯器不僅具備傳統(tǒng)編譯器的功能,如將高級語言編寫的源代碼轉換為機器可執(zhí)行的代碼,還融入了人工智能技術
    的頭像 發(fā)表于 07-17 18:28 ?1475次閱讀

    開源鴻蒙 編譯OpenHarmony輕量系統(tǒng)QEMU RISC-V版本

    本文將介紹如何為QEMU RISC-V虛擬平臺構建OpenHarmony輕量系統(tǒng)。得益于QEMU的CPU指令集模擬執(zhí)行能力,該方法可以在沒有開發(fā)板的情況下調試和運行OpenHarmony系統(tǒng)源碼。本文介紹的該方法,可以用于
    的頭像 發(fā)表于 07-15 10:36 ?985次閱讀
    開源鴻蒙 <b class='flag-5'>編譯</b><b class='flag-5'>OpenHarmony</b>輕量系統(tǒng)QEMU RISC-V版本

    鴻蒙OpenHarmony【輕量系統(tǒng) 編譯】 (基于Hi3861開發(fā)板)

    OpenHarmony支持hb和build.sh兩種編譯方式。此處介紹hb方式,build.sh腳本編譯方式請參考[使用build.sh腳本編譯源碼]。
    的頭像 發(fā)表于 05-14 17:53 ?1193次閱讀
    鴻蒙<b class='flag-5'>OpenHarmony</b>【輕量系統(tǒng) <b class='flag-5'>編譯</b>】 (基于Hi3861開發(fā)板)

    鴻蒙OpenHarmony開發(fā):【編譯構建指導】

    OpenHarmony編譯子系統(tǒng)是以GN和Ninja構建為基座,對構建和配置粒度進行部件化抽象、對內建模塊進行功能增強、對業(yè)務模塊進行功能擴展的系統(tǒng),該系統(tǒng)提供以下基本功能
    的頭像 發(fā)表于 05-13 09:31 ?1627次閱讀
    鴻蒙<b class='flag-5'>OpenHarmony</b>開發(fā):【<b class='flag-5'>編譯</b><b class='flag-5'>構建</b>指導】

    鴻蒙OpenHarmony【小型系統(tǒng) 編譯】(基于Hi3516開發(fā)板)

    OpenHarmony支持hb和build.sh兩種編譯方式。此處介紹hb方式,build.sh腳本編譯方式請參考[使用build.sh腳本編譯源碼]。
    的頭像 發(fā)表于 05-10 15:59 ?651次閱讀
    鴻蒙<b class='flag-5'>OpenHarmony</b>【小型系統(tǒng) <b class='flag-5'>編譯</b>】(基于Hi3516開發(fā)板)

    鴻蒙OpenHarmony開發(fā)板解析:【Rust模塊配置規(guī)則和指導】

    Rust是一門靜態(tài)強類型語言,具有更安全的內存管理、更好的運行性能、原生支持多線程開發(fā)等優(yōu)勢。Rust官方也使用Cargo工具來專門為Rust代碼創(chuàng)建工程和構建編譯。 OpenHarmony為了集成
    的頭像 發(fā)表于 05-10 11:32 ?1227次閱讀
    鴻蒙<b class='flag-5'>OpenHarmony</b>開發(fā)板解析:【Rust模塊配置規(guī)則和指導】

    鴻蒙OpenHarmony【標準系統(tǒng) 編譯】(基于RK3568開發(fā)板)

    OpenHarmony支持hb和build.sh兩種編譯方式。此處介紹hb方式,build.sh腳本編譯方式請參考[使用build.sh腳本編譯源碼]。
    的頭像 發(fā)表于 05-08 17:37 ?938次閱讀
    鴻蒙<b class='flag-5'>OpenHarmony</b>【標準系統(tǒng) <b class='flag-5'>編譯</b>】(基于RK3568開發(fā)板)

    【鴻蒙】OpenHarmony使用strace

    。當然也可以利用 strace 去學習了解進程的運行流程,調用庫以及參數和統(tǒng)計。那么如何在 OpenHarmony編譯使用此工具就是我們這篇文章要分享的話題。 編譯
    的頭像 發(fā)表于 03-01 09:41 ?764次閱讀
    【鴻蒙】<b class='flag-5'>OpenHarmony</b>使用strace

    鴻蒙開發(fā)【編譯構建】講解

    的詳細信息,例如執(zhí)行的編譯流程、任務的執(zhí)行時間等信息。如果在編譯構建過程中出現錯誤,您可以根據編譯任務的詳細錯誤說明進行問題的定位。 API
    發(fā)表于 02-27 17:41

    [鴻蒙]OpenHarmony4.0的Rust開發(fā)

    。 OpenHarmony 為了集成 C/C++ 代碼和提升編譯速度,使用了 GN + Ninja 的編譯構建系統(tǒng)。GN 的構建語言簡潔易讀
    的頭像 發(fā)表于 02-26 17:28 ?806次閱讀
    [鴻蒙]<b class='flag-5'>OpenHarmony</b>4.0的Rust開發(fā)

    OpenHarmony 移植:build lite 編譯構建過程

    這些疑惑,會對 build lite 編譯構建過程有個更深入的理解。 1、產品解決方案代碼是如何被調用編譯的 在文件 buildliteBUILD.gn 配置文件中的構建目標 //bu
    的頭像 發(fā)表于 02-19 16:19 ?906次閱讀

    OpenHarmony 移植:build lite 配置目錄全梳理

    命令行工具 hb (HarmonyOS|OpenHarmony Build 編譯構建系統(tǒng)的縮寫) 都很熟悉了。這是一個基于 gn 和 ninja 的構建系統(tǒng),以支持
    的頭像 發(fā)表于 02-18 16:42 ?872次閱讀

    淺談兼容 OpenHarmony 的 Flutter

    拓展,可支持使用 Flutter Tools 指令編譯構建 OpenHarmony 應用程序。 倉庫的 commit 記錄顯示,OpenHarmony 使用的 Flutter 版本是
    的頭像 發(fā)表于 02-02 15:22 ?568次閱讀
    淺談兼容 <b class='flag-5'>OpenHarmony</b> 的 Flutter

    鴻蒙南向開發(fā)—OpenHarmony技術編譯構建框架

    概述 OpenHarmony編譯子系統(tǒng)是以GN和Ninja構建為基座,對構建和配置粒度進行部件化抽象、對內建模塊進行功能增強、對業(yè)務模塊進行功能擴展的系統(tǒng),該系統(tǒng)提供以下基本功能: 以
    發(fā)表于 01-04 16:47