Makefile编译原理 make的隐性规则

一.makefile 中的同名目标

下面程序怎么执行?为什么?

Makefile编译原理 make的隐性规则_第1张图片

实验1 :makefile 中出现同名目标时

.PHONY : all 

all : 
	@echo "command-1"

all : 
	@echo "command-2"

VAR := test

all :
	@echo "all : $(VAR)"




mhr@ubuntu:~/work/makefile1$ make all
makefile:12: warning: overriding recipe for target 'all'
makefile:8: warning: ignoring old recipe for target 'all'
all : test
mhr@ubuntu:~/work/makefile1$ 
mhr@ubuntu:~/work/makefile1$ 

以最新定义的命令为准,之前定义的全部忽略。
过程:当make解释器解析这个makefile到 @echo “command-2” 的时候 ,就会将 @echo “command-2” 覆盖掉之前解析出来的 @echo “command-1” 命令。接着向下解析,当解析到 @echo “all : $(VAR)” 的时候,又将 @echo “command-2” 覆盖掉。并不是一下子就知道用哪个命令 而是从上而下的解析出来的。

Makefile编译原理 make的隐性规则_第2张图片

 注意:当使用include关键字包含其他文件时,需要确保被包含文件中的同名目标只有依赖,没有命令,否则,同名目标的命令将被覆盖。

实验2:不同makefile中相同目标的命令覆盖

makefile

.PHONY : all 

VAR := test

all : 
	@echo "all : $(VAR)"

include 1.mk

1.mk

all : 
	@echo "this is command from 1.mk"



mhr@ubuntu:~/work/makefile1$ make all
1.mk:3: warning: overriding recipe for target 'all'
makefile:8: warning: ignoring old recipe for target 'all'
this is command from 1.mk
mhr@ubuntu:~/work/makefile1$ 

二.make中的隐性规则

make 不仅仅是一个单独的脚本解释器,随着make而发布的还有一些默认实现好的规则,我们可以将这些规则的结合看成是make 的库,这是很正常的现象,当今软件 大部分解释器都自带标准库,标准库中存在一些预定义的变量,预定义的函数,以及预定义的规则,而这些预定的规则就是我们所说的隐式规则。当make 解释器发现makefile 中有目标没有提供任何的规则,此时make解释器就会去尝试去自己的标准库中查找有没有提供规则可以拿来用。如果找到了就用隐式规则,如果找不到的话才会最终报错。

下面makefile能编译成功吗?为什么?

Makefile编译原理 make的隐性规则_第3张图片

#获取所有.c源文件名字存放在 列表中
SRCS := $(wildcard *.c)

#替换后缀 得到目标文件的列表
OBJS := $(SRCS:.c=.o)


app.out : $(OBJS)
	#链接成可执行程序
	$(CC) -o $@ $^
	$(RM) $^
	@echo "Target ==> $@"

按照预想 这个程序是不会执行的,因为这个makefile 中 根本没提供任何关于 目标文件的规则啊 怎么得到目标文件呢?我们猜测 make 之后会报错。

但是实验结果是这样的:

mhr@ubuntu:~/work/makefile1$ 
mhr@ubuntu:~/work/makefile1$ make
cc    -c -o main.o main.c 
cc    -c -o func.o func.c
cc -o app.out main.o func.o
rm -f main.o func.o
Target ==> app.out
mhr@ubuntu:~/work/makefile1$ 

神奇啊? 我们的makefile中没有任何关于目标文件的规则,可是make怎么会编译得到 .o目标文件的呢??

实验的过程表明 make 是通过如下命令得到的.o文件:

cc    -c -o main.o main.c 
cc    -c -o func.o func.c

两个问题:
问题1 : 是谁指挥make 编译得到目标文件
问题2:上面的编译过程中的 cc变量哪里来的?? rm 变量哪里来的 ???

答:make 解释器在解释执行这一段代码的时候就发现,与.o目标文件相关的规则在当前的makefilez中是没有定义的,此时 make 就会到自带的标准库中寻找有没有相关的隐式规则,结果真的找到了相关的隐式规则,该规则就是 .o文件可以通过.c文件得到,通过 cc 命令 :cc -c -o xxx.o xxx.c 来产生。换句话说 在make 标准库里面必然提供了如下规则:

%.o : %.c
	$(CC) -c -o $@ $^

而 cc 变量也是 make 标准库中的定义的变量。

三.深入理解隐式规则

当make发现目标的依赖不存在时:

    尝试通过依赖名逐一查找隐式规则。

    并且通过依赖名推导可能需要的源文件。

Makefile编译原理 make的隐性规则_第4张图片

隐式规则的副作用:

编译行为难以控制,大量使用隐式规则可能产生意想不到的编译行为。

编译效率低下:

make从隐式规则和自定义规则中选择最终使用的规则。

隐式规则链:

当依赖的目标不存在时,make会极力组合各种隐式规则对目标进行创建,进而产生意料之外的编译行为。

总结:

隐式规则可能造成意想不到的编译行为。

在实际工程项目中尽量不使用隐式规则。

后缀规则是一种旧式的模式规则。

后缀规则正逐步被模式规则取代。

你可能感兴趣的:(Linux驱动,数据库,服务器,运维)