(三)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/Makefile
rules.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
.下周再会^_^
(三)openwrt主Makefile解析的更多相关文章
- OpenWrt的主Makefile工作过程
OpenWrt是一个典型的嵌入式Linux工程,了解OpenWrt的Makefile的工作过程对提高嵌入式Linux工程的开发能力有极其重要意义. OpenWrt的主Makefile文件只有100行, ...
- uboot-jiuding 下主Makefile详解
主Makefile位于uboot源码的根目录下,其内容主要结构为: 1. 确定版本号及主机信息(23至48行)2. 实现静默编译功能(48至55行)3. 设置各种路径(56至123行)4. 设置编译工 ...
- Spring Boot干货系列:(三)启动原理解析
Spring Boot干货系列:(三)启动原理解析 2017-03-13 嘟嘟MD 嘟爷java超神学堂 前言 前面几章我们见识了SpringBoot为我们做的自动配置,确实方便快捷,但是对于新手来说 ...
- uboot主Makefile分析(t配置和编译过程详解)
1.编译uboot前需要三次make make distcleanmake x210_sd_configmake -j4 make distclean为清楚dist文件. make x210_sd_c ...
- uboot总结:uboot配置和启动过程1(主Makefile分析)
说明:文件位置:在uboot的目录下,文件名为:Makefile 从文件的头部开始分析 1.24-29行,配置uboot的版本信息. VERSION = PATCHLEVEL = SUBLEVEL = ...
- SpringBoot入门(三)——入口类解析
本文来自网易云社区 上一篇介绍了起步依赖,这篇我们先来看下SpringBoot项目是如何启动的. 入口类 再次观察工程的Maven配置文件,可以看到工程的默认打包方式是jar格式的. <pack ...
- uboot主Makefile分析
VERSION = 1 PATCHLEVEL = 3 SUBLEVEL = 4 EXTRAVERSION = U_BOOT_VERSION = $(VERSION).$(PATCHLEVEL).$(S ...
- uboot 主Makefile 分析。
本文以uboot_1.1.6 对应的CPU是S3C2440 为例 uboot_1.1.6 根目录下的主Makefile开头: VERSION = PATCHLEVEL = SUBLEVEL = EXT ...
- uboot 主Makefile分析
一. Makefile 配置 1.1. make xxx_config 1.1.1. 笔者实验时是make x210_sd_config a. x210_sd_config是Makefile下的一个目 ...
随机推荐
- C#函数、参数数组(例子)★
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.T ...
- ASP.NET 取得 Uri 各项属性值
Uri uri = new Uri("http://www.yoercn.com/aboutus/idea.html");string Host = uri.Host; ...
- 【AngularJS学习笔记】01 指令、服务和过滤器
AngularJS 指令是扩展的 HTML 属性,带有前缀 ng-. 比如: ng-app 指令初始化一个 AngularJS 应用程序.注意ng-app一般为空,如果值不为空,就得加这样一句代码va ...
- Studio for ASP.NET Wijmo:使用 C1Pager 对 DataList 控件分页
Studio for ASP.NET Wijmo 控件值得称赞的一点是它不仅仅单独为 C1 控件而开发.还可以配合其他控件使用,也正体现了C1控件为提高开发人员工作效率而设计的宗旨.简单的举一个例子, ...
- Gulp-前端进阶A-3---如何不刷新监控文件变化?
npm install --save-dev gulp-connect npm install --save-dev gulp-livereload npm其他,前面已有 var gulp = req ...
- django配置fcgi参数解释
manage.py runfcgi minspare=50 maxspare=200 maxchildren=1000 maxrequests=99999 host=127.0.0.1 port=80 ...
- 小型工厂企业网站究竟该怎么做好SEO优化,从而带来更多订单?
中 小企业以及小型工厂做好SEO工作,每年从SEO带来的订单量还是很可观的,随着互联网的蓬勃发展,越来越多的小型工厂型企业网站开始逐渐走向互联网营 销,开始逐渐利用互联网开展销售工作!但是大部分的工厂 ...
- Android使用默认样式创建View的几个姿势
以下内容是分析安卓源码所得: 1: 使用默认样式创建View的方式, 源码文件 Button.Java 注:此文参考http://www.linzenews.com/ 中的内容所写,如侵删! 2: ...
- MUI - 将tap模拟成原生click体验
mui提供了tap事件替换了html5的click事件,解决了300ms延时的问题.不过相比原生app的click体验还是有些许差距的.关于300ms延时的问题,这篇帖子分析的比较完善,其中提到了穿透 ...
- windows上JSP开发环境全搭建
JSP开发环境全搭建 最近需要用到JSP做项目,所以要配置JSP的开发环境,总结一下配置步骤以备以后再配置需要. 配置JAVA开发环境,配置JDK 下载JDK,在这里下载开发所需的JDK,可以根据自己 ...