在构建镜像的时候你肯定看到了很多的makefile文件,昨天我们也解读一些一些构建编译的makefile文件,但是有些兄弟没有这方面的经验,对于makefile文件的格式还是不是很熟悉。
其次make是我们编译时的关键命令,这也顺便来讲讲它和makefile的渊源。
最后如果你的内核是构建去做安卓方面的事情,这里面会有很多.mk文件,那么这个文件又是什么,下面一起来看看吧。
makefile关系到了整个工程的编译规则。一个工程中的源文件不计其数,并且按类型、功能、模块分别放在若干个目录中,**makefile定义了一系列的规则来指定,哪些文件需要先编译,哪些文件需要后编译,哪些文件需要重新编译,**甚至于进行更复杂的功能操作。
所以为什么有这个东西的目的显然–>因为一个大的工程数以万计的文件,你很难去正确快速的进行手动链接编译,因此使用makefile统一管理。(比如linux内核的source code)
makefile带来的好处就是——“自动化编译”,一旦写好,只需要一个make命令,整个工程完全自动编译,极大的提高了软件开发的效率。make是一个命令工具,是一个解释makefile中指令的命令工具,一般来说,大多数的IDE都有这个命令
make命令执行时,需要一个makefile文件,以告诉make命令需要怎么样的去编译和链接程序。
makefile说明make make解释makefile
那.mk是什么?.mk是一种android编译环境下的一种特殊的“makefile”文件,mk文件最终还是要被android编译系统层层解析,转化为make命令能够读懂的格式,从而调用gcc编译器进行编译,暂时在我没有对其有更深的认识之前,我也把其当做一种特殊领域的makefile文件。只不过经过android编译系统的一大堆处理,android.mk的格式就变得非常简单,且与普通的makefile文件书写格式不一样了。
(一个成熟的开发框架必然有自己的打包系统,比如C或C++项目中的make文件、Java项目中的ant工具等,NDK也有自己的打包配置文件,这些文件以mk为后缀。Android.mk文件是NDK的编译脚本,用于把C或C++代码编译成so文件。)
(Android NDK的全称是Android Native Development Kit,顾名思义,就是原生代码调用,实际上就是允许Java程序通过JNI调用C或C++的动态链接库(so文件)。)
下面分为三个部分来讲讲具体的使用,如果你的嵌入式系统不是按安卓,可能其实你不需要看这个.mk,但是作为搞技术的,多学点没毛病的哦。
原文链接
想要书写一个完整的 Makefile文件,需要了解 Makefile 的相关的书写规则。我们已经知道了 Makefile 描述的是文件编译的相关规则,它的规则主要是两个部分组成,分别是依赖的关系和执行的命令,其结构如下所示:
targets : prerequisites
command
或者是
targets : prerequisites; command
command
相关说明如下:
targets:规则的目标,可以是 Object File(一般称它为中间文件),也可以是可执行文件,还可以是一个标
prerequisites:是我们的依赖文件,要生成 targets 需要的文件或者是目标。可以是多个,也可以是没有;
command:make 需要执行的命令(任意的 shell 命令)。可以有多条命令,每一条命令占一行。
注意:我们的目标和依赖文件之间要使用冒号分隔开,命令的开始一定要使用Tab键。
通过下面的例子来具体使用一下 Makefile 的规则,Makefile文件中添代码如下:
test:test.c
gcc -o test test.c
上述代码实现的功能就是编译 test.c 文件,通过这个实例可以详细的说明 Makefile 的具体的使用。其中 test 是的目标文件,也是我们的最终生成的可执行文件。依赖文件就是 test.c 源文件,重建目标文件需要执行的操作是gcc -o test test.c。这就是 Makefile 的基本的语法规则的使用。
使用 Makefile 的方式:首先需要编写好 Makefile 文件,然后在 shell 中执行 make 命令,程序就会自动执行,得到最终的目标文件。
通过上面的例子我们可以了解到,Makefile 的规则很简单,但这并不是 Makefile 的全部,这个仅仅是它的冰山一角。仅仅靠一个规则满足不了我们对于大的工程项目的编译。甚至几个文件的编译都会出现问题,所以要学习的东西还有很多。
简单的概括一下Makefile 中的内容,它主要包含有五个部分,分别是:
1) 显式规则
显式规则说明了,如何生成一个或多的的目标文件。这是由 Makefile 的书写者明显指出,要生成的文件,文件的依赖文件,生成的命令。
2) 隐晦规则
由于我们的 make 命名有自动推导的功能,所以隐晦的规则可以让我们比较粗糙地简略地书写 Makefile,这是由 make 命令所支持的。
3) 变量的定义
在 Makefile 中我们要定义一系列的变量,变量一般都是字符串,这个有点像C语言中的宏,当 Makefile 被执行时,其中的变量都会被扩展到相应的引用位置上。
4) 文件指示
其包括了三个部分,一个是在一个 Makefile 中引用另一个 Makefile,就像C语言中的 include 一样;另一个是指根据某些情况指定 Makefile 中的有效部分,就像C语言中的预编译 #if 一样;还有就是定义一个多行的命令。
5) 注释
**Makefile 中只有行注释,和 UNIX 的 Shell 脚本一样,其注释是用“#”字符,**这个就像 C/C++ 中的“//”一样。如果你要在你的 Makefile 中使用“#”字符,可以用反斜框进行转义,如:“#”。
内容真的还是蛮丰富的,很多前辈已经给出了很好的教程,就不再重复了
推荐学习资料:阮一峰老师的教你怎么写makefile
[跟我一起写 Makefile](https://blog.csdn.net/haoel/article/details/2886)
make只是一个根据指定的Shell命令进行构建的工具。它的规则很简单,你规定要构建哪个文件、它依赖哪些源文件,当那些文件有变动时,如何重新构建它。
1、可以简单的使用make或者在make命令后带上目标all
2、通过 -B 选项让所有目标总是重新建立
3、使用 -d 选项打印调试信息
4、使用 -C 选项改变目录
5、通过 -f 选项将其它文件看作 Makefile
原文链接
对于工具的学习我都是希望能看到简单的东西,大致有个认识,对于复杂可以在实际使用的时候去慢慢熟悉,当然每个人适合的不一样,just follow your heart.
(1)LOCAL_PATH:=$(call my-dir)
LOCAL_PATH是每个Android.mk文件都必须定义的,用于指定项目的根目录,编译器会在此目录树中查找代码源文件。另外,“call my-dir”语句返回的是当前目录路径。
(2)include$(CLEAR_VARS)
include语法用于包含外部库(C Library),CLEAR_VARS由编译系统提供,对应的GNU Makefile脚本会为我们清除LOCAL_PATH以外的所有以LOCAL_为前缀的变量,如LOCAL_MODULE、LOCAL_SRC_FILES、LOCAL_STATIC_LIBRARIES等。
这是必要的,因为所有的编译控制文件都在同一个GNU Make环境中。
(3)LOCAL_MODULE:=hello-jni
LOCAL_MODULE也是必须定义的,用于标识C工程中的各个模块,最终的链接库文件的名称也与此值有关,比如这里生成的so文件名就是libhello-jni.so。另外,LOCAL_MODULE值必须是唯一的,且不能含有空格。
(4)LOCAL_SRC_FILES:=hello-jni.c
LOCAL_SRC_FILES用于指定C工程的源代码文件,当然如果包含多个文件可以使用“\”符号进行换行。这里不需要包含头文件,系统会自动为我们准备好。另外,如果要使用不同的C++文件名,可以通过配置LOCAL_DEFAULT_CPP_EXTENSION参数来指定。
(5)include$(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY也由编译系统提供,对应的GNU Makefile脚本会为我们收集所有以LOCAL_为前缀的变量,这可以让C工程的类库和代码更加清晰,而我们也可以通过配置参数BUILD_STATIC_LIBRARY来生成静态库。比如,使用“include$(BUILD_STATIC_LIBRARY)”就将生成以.a为后缀的静态库。
当然,除了前面介绍的常用系统变量,如CLEAR_VARS、BUILD_SHARED_LIBRARY以及BUILD_STATIC_LIBRARY之外,Android.mk文件还支持以下变量。
TARGET_ARCH:用于指定CPU类型,常见的值有arm和x86。
TARGET_PLATFORM:用于指定Android平台的版本。
TARGET_ARCH_ABI:用于指定CPU+ABI的类型,比如armeabi就代表Armv5TE的指令集架构。虽然目前支持的类型只有两种,但是在未来的NDK版本中可能会出现更多的选择。
然后,再来看看除了常用的模块描述变量,如LOCAL_PATH、LOCAL_MODULE、LOCAL_SRC_FILES以及LOCAL_CPP_EXTENSION之外,Android.mk文件还支持的变量。
LOCAL_C_INCLUDES:可选项,表示C或C++头文件的搜索路径,一般是项目目录的相对路径。·
LOCAL_CFLAGS:可选的编译选项,在编译C代码时使用,在使用附加包或者宏定义的时候比较有用,比如LOCAL_CFLAGS:=-DHHH等价于头文件中的#define HHH。·
LOCAL_CXXFLAGS:同LOCAL_CFLAGS,只不过针对的是C++代码。·
LOCAL_CPPFLAGS:同LOCAL_CFLAGS,对C或者C++代码都适用。·
LOCAL_STATIC_LIBRARIES:表示模块编译时需要用到的静态库。·
LOCAL_SHARED_LIBRARIES:表示模块编译时需要用到的共享库(动态库)。·
LOCAL_LDLIBS:编译时需要使用的链接器选项,比如-lz就代表需要链接到libz.so库。
最后,再来学习一下Android.mk文件中可用的宏定义。·
my-dir:返回当前目录。·
all-subdir-makefiles:返回所有子目录的Android.mk文件的路径列表。·
this-makefile:返回当前Android.mk文件的路径。·
parent-makefile:返回调用数中父级的Android.mk文件路径。
APP_PROJECT_PATH:用于给出应用程序工程的根目录的一个绝对路径。·
APP_MODULES:用于列出应用所需的所有模块,如果没有定义,NDK将会对Android.mk中声明的默认模块进行编译。
APP_OPTIM:可选模式有release或debug两种,分别表示编译的应用是发布版还是调试版的。如果是发布版(release模式),编译器会生成更加优化的二进制文件,利于运行;而调试版(debug模式)则更利于调试。·
APP_CFLAGS:功能同Android.mk的LOCAL_CFLAGS。·
APP_CXXFLAGS:功能同Android.mk的LOCAL_CXXFLAGS。·
APP_CPPFLAGS:功能同Android.mk的LOCAL_CPPFLAGS。·
APP_BUILD_SCRIPT:指定编译脚本,默认情况下NDK编译器会在项目的jni目录下寻找名为Android.mk的文件。·
APP_ABI:选择指令集,可选项包括armeabi、armeabi-v7a以及x86。
以上就是对于这个部分的理解,大家对于工具的学习我建议是建立在需求之上的,不然来的也快,忘得也超级快的。