Hi3861 业务代码编写框架

前言：

        业务代码通过 ninja 进行构建，类似于 make，同时借助于 gn 生成 ninja 构建规则，类似于 cmake，所以我们编写业务代码除了关注代码本身的内容外，还要将代码添加到 gn 的构建规则中去。

        这种风格是继承自 linux 编译框架的风格，可能用惯了 STM32 啥单片机的小伙伴会觉得这个编译流程是老太太的裹脚布-又臭又长，有这种想法很正常，我刚接触的时候也想，搞一个 MCU 级别的小芯片，编译流程做的这么麻烦，不是劝退使用者嘛，实际上这些是对 LiteOS 内核适配，LiteOS 做的很大，最小都要 128K 的 ROM，对于 STM32F103C8 来说，移植都没法移植，不像 RT-Thread、FreeRTOS，最小 10K ROM 就能实现功能了，所以主观就觉得 LiteOS 拉胯。

        实际上 LiteOS 设计和应用的场景一般不是应用于 这种极小资源的芯片的，在很多场景下用在多核的 MCU、AIOT 芯片等等，内核编译框架需要有强大的多核开发支持，所以其编译框架有着很浓厚的 Linux 编译背景，学习的小伙伴也不要觉得麻烦，这可以作为向 linux 开发学习进军的一个小跳板呢！

代码目录规则：

下面继续研究 Hi3861，目前官方给出的目录规则框架如下：

.
└── applications       
    └── BearPi
        └── BearPi-HM_Nano
            └── sample
                │── my_first_app
                │  │── hello_world.c
                │  └── BUILD.gn
                └── BUILD.gn

那我按照官方的规则来建立一个测试代码目录，我的如下：

.
└── applications        
    └── BearPi
        └── BearPi-HM_Nano
            └── sample
                │── test_app
                │  │── test.c
                │  └── BUILD.gn
                └── BUILD.gn

业务代码：

.c 文件内容，就是一个简单的打印程序：

#include "ohos_init.h"
#include "ohos_types.h"
#include 
void test(void)
{
    printf("[DEMO] Hello world Test.\n");
}
SYS_RUN(test);

SYS_RUN 用于将函数注册到 LiteOS 系统的运行代码中执行。

最小代码单元：

最小特性的配置文件（和源代码同级目录的 gn 文件）用于每个代码模块的编译，代码如下：

static_library("testapp") {
    sources = [
        "test.c"
    ]
    include_dirs = [
        "//utils/native/liteos/include"
    ]
}

该文件定义了 testapp 的编译规则，他的源文件和头文件目录，其中 // 是工程目录

组件单元：

上一级目录的 gn 文件代码如下，定义了组件的依赖关系，定义了 app 组件的特性包含 a_test_app 目录下的 testapp 静态库，编译时将它加入

import("//build/lite/config/component/lite_component.gni")
lite_component("app") {
    features = [
        "a_test_app:testapp",
    ]
}

编译结果：

代码编译结果如下：

烧写测试，看看有没有将代码添加到启动过程，可以看到执行打印出我写的代码了：