首先我们来看看.gn文件:
刚开始我和大家一样也是看的一头雾水,但是等大家通读完这篇文件就知道如何看GN文件啦!
首先GN是一个为Ninja生成构建文件的构建系统,目的是为了工程师更高效的makefile
由于想要使它具备高效性,所以当初设计的理念如下:
a = ["first"]
a += ["second"]
b = a + ["third","fourth"]
b -= ["second"]
if(is_Linux || target_cpu == "x86"){
sources -= ["lite.c"]
}else if(……){
……
}
类似C语言的条件分支
foreach(i, list){
print(i)
}
一般来说构建的大多数事情是不需要循环来表达的,所以不建议使用循环
函数调用
类似C语言,接收{}括起来的代码块
作用域
文件和函数调用后{}引入新的作用域,作用域是嵌套的
整个流程如下:首先在当前目录下查询.gn文件,不存在时像上级目录查询,直到找到一个设置为sourceroot,解析该gn文件获得bulid config文件名称。然后执行build config,根据root目录下的build.gn文件找到目标其依赖的其他目录下的bulid.gn文件——当所有的目标依赖都找到后编译出.ninja
其中涉及的目标时构造表中的一个节点,通常用于表示某个要产生的可执行或库文件,目标之间相互依赖,GN内置的一些目标类型:
配置时指定标志集,包含目录和定义的命名对象,可以应用于目标并推送到依赖目标,比如第三方目标——需要一些定义或包含目录才能使其头文件正常导入
config("config"){
includes = ["src/include"]
defines = ["HUKS_MESSAGE"]
}
将其应用于目标:
executable("service"){
configs += [":config"]
}
build config文件通常指定设置默认配置列表的目标默认值。所以实践中我们通常把自定义的config以configs += [":config"]的方式添加
在上面的例子中我们就可以看的import的使用,我们可以使用import将.gni导入当前文件中,这里的import机制与C中的不太一样,它是将import的文件执行完毕的内容复制到当前文件中
这里大家就要问了.gni文件是什么?不是只有.gn文件吗?——这就是接下来要讲的复用的template模板
一般来说模板定义在.gni文件中,用户import该文件看的模板的定义并使用
//模板的定义
template("ipc"){
ipc_target_name = "xxx"
……
}
//模板的调用
import("//tools/ipc_utils.gni")
ipc("my_interfaces"){
……
}
由于知识水平的有限以及对鸿蒙研究不够深入,所以贴上别的研究者的一篇博客分析的比较清楚:
GN在harmony中的实际应用
首先我们找到外围的build.gn
可以看的这是用于test的构建文件目录,我们顺着路径再往下找
可以看到给出了很多测试的文件和目录,下面也给出了其依赖的目标deps
通过.gn文件我们很方便的将整个文件结构组织起来
首先这是一个资源文件,里面包括了引入的位图文件,窗口,图标,光标等等。
拿EXE文件举例,如果要生成一个.exe文件,文件的图标是我们自定义的图标,我们就需要添加该图标并保存到.rc中
.rc文件实质上是一类txt文本文件与.h文件配合使用