Openharmony添加编译自己应用

介绍一下Openharmony如何在庞大的编译构建系统中,增添自己想编译的内容。不定期更新~🐸

gn官方文档:

openharmony官方build文档:

AuthorDateVersionDescription
陈梓归、唐凯文2023-05-15V1.0第一个版本

 1. 编译自带libdrm/modeset程序

OH的源码环境下third_party/libdrm/tests下是有测试程序的,但是不会编译,需要自己写BUILD.gn来进行编译;

1.1 modeset添加BUILD.gn

  • 注意:只有sources和part_name是必选,其他都是可选的;
##  third_party/libdrm/tests/modetest/BUILD.gn
# 使用模板,用import,类似C语言的#include
import("//build/ohos.gni")
# 生成可执行文件,叫作modetest
ohos_executable("modetest"){
    # 依赖编译相关文件
    sources = [
        "buffers.c",
        "cursor.c",
        "modetest.c",
    ]
    cflags = [
        "-Wno-pointer-arith",
    ]
    include_dirs = [
        "../",
        ".",
    ]

    # 配置
    configs = [ "//third_party/libdrm:libdrm_config" ]
    public_configs = [ "//third_party/libdrm:libdrm_public_config" ]

    # 部件内模块依赖
    deps = [
        "//third_party/libdrm:libdrm",
        "//third_party/libdrm/tests/util/:util",
    ]
    public_deps = []
    
    # 可选,缺省在/system/lib64或/system/lib下, 模块安装路径,模块安装路径,从system/,vendor/后开始指定
    # module_install_dir = ""
    # 可选,模块安装相对路径,相对于/system/lib64或/system/lib;如果有module_install_dir配置时,该配置不生效  
    # relative_install_dir = "" 
    # 可选,缺省值system,指定模块安装到那个分区镜像中,可以指定多个
    install_images = [
        "system",
    ]
    # 必选,所属部件名称
    part_name = "graphic_standard"
    # 可选,所属子系统名称
    subsystem_name = "graphic"
}

1.2 为 modetest构建依赖util

在前面的BUILD.gn中我们看到了modeset依赖了util,所以我们这里必须为util构建编译脚本!

因为libdrm会自动构建,所以我们不需要自己构建编译啦😄

## third_party\libdrm\tests\util\BUILD.gn
import("//build/ohos.gni")

ohos_static_library("util"){
    sources = [
        "format.c",
        "kms.c",
        "pattern.c",
    ]

    include_dirs = [
        "../",
        "."
    ]

    configs = [ "//third_party/libdrm:libdrm_config" ]

    public_configs = [ "//third_party/libdrm:libdrm_public_config" ]
    cflags = [
        "-Wno-unused-variable",
        "-Wno-sign-compare",
    ]

    deps =[
        "//third_party/libdrm:libdrm",
    ]
    public_deps = []
}

1.3 将modetest加入到OHOS编译系统

这里比较简单,可以搜一搜哪个编译的依赖libdrm,然后选择一个加入到BUILD.gn即可

  • 搜索//third_party/libdrm:libdrm
 deps = [
    "//third_party/libdrm:libdrm",
    "//third_party/libdrm/tests/util/:util",
    "//third_party/libdrm/tests/modetest/:modetest",
  ]

1.4 编译

  • --build-target=ohos_executable的名字

编译命令:./build.sh --product-name d2000 --target-cpu arm64 --build-target=modeset --jobs=100

  • 报错:
../../third_party/libdrm/tests/util/pattern.c:988:8: error: unused variable 'mem_base' [-Werror,-Wunused-variable]
  • 解决:
第一个方法:屏蔽这行
第二个方法:修改cflags参数
注意这里的cflags需要添加到libdrm下面的BUILD.gn才可以,不然也会编译不过!
修改libdrm文件下面的BUILD.gn加入
        "-Wno-unused-variable",
        "-Wno-sign-compare",
        "-Wno-pointer-sign",
        "-Wno-deprecated-declarations",

2. 添加自己应用

2.1 在libdrm下建立对应的fovt_app文件夹

  • 增加对应的gn文件和.c文件,然后按照上面的方法增加到一个编译里面去;
  • gn
#fovt test application
import("//build/ohos.gni")

#单独编译它
#./build.sh --product-name d2000 --target-cpu arm64 --build-target=atomic_test
ohos_executable("atomic_test"){
    sources = [
        "atomic_test.c",
    ]
    output_name = "atomic_test"

    cflags = [
        "-Wno-pointer-arith",
    ]

    include_dirs = [
        "../",
        ".",
    ]

    configs = [ "//third_party/libdrm:libdrm_config" ]

    public_configs = [ "//third_party/libdrm:libdrm_public_config" ]

    deps = [
        "//third_party/libdrm:libdrm",
    ]

    public_deps = []

    install_images = [
        "system",
    ]
    part_name = "graphic_standard"
    subsystem_name = "graphic"
}

<think>好的,用户现在问的是为什么OpenHarmony源码需要编译。首先,我需要回顾一下之前的对话历史。用户之前询问过Flash在开发领域的含义,我详细解释了Flash存储器的相关内容,可能用户现在在接触嵌入式开发或者物联网设备相关的项目,所以转向了OpenHarmony。 用户可能正在学习或使用OpenHarmony,遇到了需要编译源码的情况,但不太明白为什么不能直接使用源码,而必须经过编译。需要解释编译的必要性,可能涉及操作系统的基本概念,编译的作用,以及OpenHarmony本身的特性。 接下来,我需要分析用户的问题。用户想知道为什么需要编译,可能他们不太了解编译过程的意义,或者遇到了编译相关的问题,想理解背后的原因。需要从多个方面回答,比如源码到可执行代码的转换、跨平台支持、系统定制化、资源优化、功能模块化、验证与调试、安全加固等。 还要考虑用户可能的背景,可能是开发者,但刚入门,对操作系统开发不太熟悉。需要以简明易懂的方式解释,避免使用过多专业术语,或者至少解释清楚术语。同时,可能需要对比其他操作系统如Linux或Android的编译过程,但重点放在OpenHarmony的特殊性上。 另外,用户的问题可能隐含着更深层次的需求,比如如何优化编译过程,或者解决编译中的问题,但当前问题主要是解释原因。需要确保回答结构清晰,分点说明,每个点都有具体例子或类比,帮助用户理解。 还要注意之前的回复中提到了Flash存储器在嵌入式系统中的应用,特别是OpenHarmony的设备固件存储,所以可能需要将编译与Flash存储联系起来,比如编译后的固件需要烧写到Flash中运行。这可能是一个连接点,但用户当前的问题集中在编译的必要性上,所以重点还是编译本身。 需要检查是否有其他可能的解释,比如OpenHarmony的架构设计是否需要编译,或者是否支持多种设备形态导致必须通过编译来适配不同硬件。这些都是关键点,需要涵盖在内。 最后,总结的时候要强调编译是构建操作系统不可或缺的步骤,无论是为了适配硬件、优化性能还是实现功能定制。可能还需要提到工具链和构建系统,如Gn和Ninja,这些都是OpenHarmony编译过程的一部分,帮助用户更全面地理解。 总结下来,回答的结构应该是:解释编译的基本概念,列出几个主要原因,每个原因详细说明,结合OpenHarmony的特点,最后总结编译的重要性。同时,保持语言通俗易懂,避免过于技术化,但也要准确无误。</think>在开发领域,**编译(Compile)**是将人类可读的源代码(如C/C++、Java等)转换为机器可执行的二进制代码(如机器指令、字节码等)的过程。对于 **OpenHarmony**(开源鸿蒙操作系统)这类复杂的操作系统而言,编译是构建系统功能、适配硬件设备、优化性能的关键步骤。以下是其源码需要编译的核心原因: --- ### **1. 源码到可执行代码的转换** - **源码的本质**: OpenHarmony的源码(如内核、驱动、应用框架)是以高级语言(如C、C++、JavaScript)编写的文本文件,CPU无法直接理解。 - **编译的作用**: 通过编译器(如GCC、LLVM)将源码转换为目标硬件(如ARM芯片、RISC-V芯片)能直接执行的二进制指令,例如: ```c // 源码示例(函数逻辑) int add(int a, int b) { return a + b; } ``` 编译后可能变为机器码:`0x01 0x03 0x05...`(具体值取决于指令集)。 --- ### **2. 跨平台适配与硬件兼容** - **多设备支持**: OpenHarmony定位为“全场景分布式操作系统”,需支持手机、智能家居、车载设备等不同硬件架构(如ARM、x86、RISC-V)。 **编译时需指定目标平台**,例如: ```shell # 编译为ARM架构 ./build.sh --product-name rk3568 --target-cpu arm64 ``` - **硬件驱动集成**: 不同设备的传感器、屏幕、通信模块等硬件差异大,编译过程中需将对应的驱动代码与内核绑定,生成适配特定硬件的系统镜像。 --- ### **3. 系统定制与模块裁剪** - **按需构建系统功能**: OpenHarmony支持轻量级(LiteOS)到标准版的多形态部署。通过编译配置(如`build.gn`文件),可灵活选择所需模块(如是否包含图形界面、AI框架等)。 例如: ```python # 在构建配置中启用图形子系统 declare_args() { enable_graphic_ui = true } ``` - **资源优化**: 编译时可通过代码优化(如删除未使用的函数、压缩资源文件)减少系统体积,提升运行效率(尤其对内存受限的物联网设备至关重要)。 --- ### **4. 依赖管理与代码整合** - **解决代码依赖**: OpenHarmony包含内核、子系统、第三方库(如OpenSSL)等模块,编译工具(如Gn、Ninja)会自动化处理依赖关系,确保组件按正确顺序构建。 - **生成完整系统镜像**: 编译过程会将内核、驱动、系统服务、应用程序等代码整合为可刷写的镜像文件(如`system.img`、`vendor.img`),方便烧录到设备存储(如Flash芯片)。 --- ### **5. 安全加固与性能优化** - **代码保护**: 编译时可启用安全特性(如地址随机化ASLR、栈保护),或对敏感代码进行混淆,增强系统抗攻击能力。 - **性能调优**: 编译器可针对目标硬件进行指令级优化(如SIMD指令加速、循环展开),提升系统响应速度与能效比。 --- ### **6. 验证与调试** - **静态检查**: 编译过程中,工具链会对代码进行语法检查、类型检查,提前发现潜在错误。 - **生成调试信息**: 编译添加调试符号(如`-g`选项),便于开发者通过GDB等工具分析系统运行时的状态。 --- ### **总结:OpenHarmony编译的核心目标** | **阶段** | **输入** | **输出** | **核心意义** | |----------------|-------------------------|---------------------------|----------------------------------| | **预处理** | 源码(.c/.cpp) | 展开宏/头文件的临时文件 | 处理代码依赖与条件编译 | | **编译** | 预处理后的代码 | 汇编代码(.s/.o) | 转换为低级语言 | | **链接** | 目标文件(.o) + 库文件 | 可执行文件(.bin/.elf) | 整合代码与资源,生成最终系统镜像 | 编译OpenHarmony从“通用代码”变为“可运行系统”的必经之路,其本质是通过工具链将开发者编写的逻辑精准适配到硬件,同时实现功能、性能与安全的平衡。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

种瓜大爷

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值