(三)openwrt主Makefile解析
本周成胖子每周一博到了第四周^_^
前言
前一篇,我们大概描述了整个镜像文件的生成过程.本周我们来解析主Makefile,看看主要编译过程是怎么产生的.
主Makefile结构
我们以chaos calmer的代码为例,整个编译的入口是在源码根目录下的Makefile.编译的各种命令都应该在源码根目录下键入.
整个主Makefile的结构如下:
world:
ifneq ($(OPENWRT_BUILD),1)
顶层
else
第二层
endif开始部分是一些注释和变量定义及路径检查.
根据Makefile的规则,在没有指定编译目标的时候,Makefile中的第一个目标将作为默认目标.
换句话说,当我们执行make V=s时,这个时候编译的目标就是world.和我们执行make world V=s效果是一样的.
顶层
通常在编译时,我们不会定义变量OPENWRT_BUILD的值,所以通常我们是会走到顶层的.
顶层代码如下:
_SINGLE=export MAKEFLAGS=$(space);
override OPENWRT_BUILD=1
export OPENWRT_BUILD
GREP_OPTIONS=
export GREP_OPTIONS
include $(TOPDIR)/include/debug.mk
include $(TOPDIR)/include/depends.mk
include $(TOPDIR)/include/toplevel.mk这里我们看到变量OPENWRT_BUILD被置为1.然后包含了3个.mk文件.
这里稍微解释下.mk文件.它们一般没有什么执行动作,都是一些变量的定义还有依赖关系的说明.可以类比于C语言的头文件来理解.
debug.mk:
可以通过定义DEBUG的值来控制编译过程
depends.mk
主要定义了rdep这个变量
toplevel.mk
这个是我们跟踪编译过程的重要的文件.这个文件在源码根目录下的
include文件夹下.
核心代码如下:
%::
@+$(PREP_MK) $(NO_TRACE_MAKE) -r -s prereq
@( \
cp .config tmp/.config; \
./scripts/config/conf --defconfig=tmp/.config -w tmp/.config Config.in > /dev/null 2>&1; \
if ./scripts/kconfig.pl '>' .config tmp/.config | grep -q CONFIG; then \
printf "$(_R)WARNING: your configuration is out of sync. Please run make menuconfig, oldconfig or defconfig!$(_N)\n" >&2; \
fi \
)
@+$(ULIMIT_FIX) $(SUBMAKE) -r $@ $(if $(WARN_PARALLEL_ERROR), || { \
printf "$(_R)Build failed - please re-run with -j1 to see the real error message$(_N)\n" >&2; \
false; \
} )除了少数在toplevel中被定义的目标外,其他编译目标都会走到这里.将之简化后:
%::
make prereq
make $@首先执行prereq,然后再执行我们指定的目标或者默认目标world.
prereq整理后的依赖关系如下:
其中
staging_dir/host/.prereq-build:
将会执行一系列主机检查,是否安装了必要的软件.
prepare-tmpinfo:
根据scan.mk,扫描
target/linux和package目录,生成packageinfo和targetinfo.
总之,顶层完成一系列必要的准备工作.对于绝大多数的目标而言,顶层是必经之路.当然,在toplevel.mk中,我们也可以看到目标menuconfig.也就是说对于目标menuconfig而言,将不会执行到第二层的逻辑.
第二层
在上面执行完make prereq之后,将执行make world.
还记得我们进入顶层后修改了变量OPENWRT_BUILD么?当再次执行make world的时候,由于条件不满足,我们将直接进入第二层来执行.
include rules.mk
include $(INCLUDE_DIR)/depends.mk
include $(INCLUDE_DIR)/subdir.mk
include target/Makefile
include package/Makefile
include tools/Makefile
include toolchain/Makefilerules.mk:
很重要的一个mk文件,其中规定了很多有用的变量,包括各种目录路径的定义,交叉编译器等等.其中
ifeq ($(DUMP),) -include $(TOPDIR)/.config endif就是包含了我们的配置文件.对于
Makefile而言,.config文件就是一大串变量的定义.Makefile可以直接读取这些定义,从而控制编译过程.
subdir.mk:
这个是读懂我们整个编译过程的关键所在,其中主要定义了两个函数:subdir和stampfile,我们稍后加以解释.
接下来,包含了4个Makefile文件.我们以target/Makefile为例.该文件位于target目录下.
核心部分为:
$(eval $(call stampfile,$(curdir),target,prereq,.config))
$(eval $(call stampfile,$(curdir),target,compile,$(TMP_DIR)/.build))
$(eval $(call stampfile,$(curdir),target,install,$(TMP_DIR)/.build))
$(eval $(call subdir,$(curdir)))这里调用了subdir.mk中定义的stampfile函数.将会生成target/stamp-prereq,target/stamp-compile,target/stamp-install三个变量.
以target/stamp-prereq为例,执行部分为make target/prereq.同理target/stamp-compile,执行部分为make target/compile.
最后又调用了sbudir函数,这个函数规定了目标和各子文件夹之间的依赖关系.如果有一定的Makefile基础可以去读读subdir.mk文件.
举例而言就是:
当执行目标为
target/compile,这个目标将依赖于target/linux/compile.
当执行目标为package/compile,这个目标将依赖于package目录下,各子文件夹的compile.
下面就是规定了一系列的依赖关系,我已经将他们梳理了出来,如下图:
这里就是第二层解析后的依赖关系.当依赖关系生成后,将会从最先被依赖的目标开始执行.
比如我们可以看到进入第二层后,tools/stamp-install将会最先被执行,也就是主机工具将会最先被编译,安装.我们上一篇提高的整个编译过程能从上图中得出.
尾记
- 想要读懂Makefile,首先要梳理各个依赖关系.而要梳理各个依赖关系,关键要关注冒号和
make -C - 本周我们解析了主Makefile,在Makefile的执行过程中要理解make的执行过程.先读入Makefile,然后构建依赖关系,最后最先被依赖的目标将会先执行.
- 我主要描绘了主要枝干,如果希望了解更多细节,还是要自己去阅读Makefile.
- 接下来两篇,我们将主要分析下,和我们开发者比较相关的两个目标的执行过程:
package/stamp-compile和target/stamp-install.下周再会^_^
