如果我们将同一个目标的命令拆分的写到不同地方,会发生什么呢?我们来看看下面的代码
.PHONY : all all : @echo "command-1" VAR := test all : @echo "all : $(VAR)"
我们来分析下,这份代码中有两个目标 all,那么我们在执行 make 的时候。它到底是执行哪个呢?一个可能是两个都执行,另一个就是执行第一个,因为默认的是执行第一个目标。下来我们来看看执行结果
我们看到它说 all 重复了,便忽略了前面的 all 命令。最终执行的是最后一个 all 命令。因此,当 makefile 中出现同名目标时,会将所有的依赖合并在一起,成为目标的最终依赖;当多处出现同一目标的命令时,make 发出警告,所有之前定义的命令被最后定义的命令取代。注意:当使用 include 关键字包含其他文件时,需要确保被包含文件中的同名目标只要依赖,没有命令;否则,同名目标的命令将被覆盖!我们还是来看看,再建立一个新的 makefile.1
makefile.1 源码
all : @echo "this is command from makefile.1"
makefile 源码
.PHONY : all VAR := test all : @echo "all : $(VAR)" include makefile.1
我们来看看编译结果,看看打印出的是不是 all : test
我们看到输出的是 "this is command from makefile.1,并不是我们所期望的 all : test。其实也不难理解,因为我们包含的 makefile.1 中也包含了 all 命令,因此将上面的 all 给替换了。换句话说,这个现象有可能会给我们带来意想不到的结果。那么这也就属于 makefile 中的一条隐式规则了,什么是隐式规则呢?在 make 中,它提供了一些常用的,例行的规则实现;当相应目标的规则未提供时,make 尝试使用隐式规则。那么我们来看看下面这个 makefile 能编译成功吗?
.PHONY : all SRCS := $(wildcard *.c) OBJS := $(SRCS:.c=.o) app.out : $(OBJS) $(CC) -o $@ $^ $(RM) $^ @echo "Target ==> $@"
我们看看编译的结果,是否会报错?
我们看到已经正确的编译了,而且结果也是对的。那么我们并没有在里面定义相应的规则啊,为什么就能正确编译呢?我们按照它的格式写个规则,再将 cc 换成 gcc 试试,看看结果是否会相同?
.PHONY : all CC := gcc SRCS := $(wildcard *.c) OBJS := $(SRCS:.c=.o) app.out : $(OBJS) $(CC) -o $@ $^ $(RM) $^ @echo "Target ==> $@" %.o : %.c @echo "my rule" $(CC) -c -o $@ $^
编译结果如下
结果和之前是一样的,只不过是输出了我们自定义的语句,将 cc 换成了 gcc。那么 cc 是什么呢?为何能编译源文件呢?cc 第一个 c 是 C 语言,第二个是 compiler 编译器的意思。那么这个 cc 编译器是哪来的呢?在原来的 Unix 系统中是有 cc 编译器的,因为它是商业版的,需要收费,因此在 Linux 系统中也是要支持 cc 的,不过此 cc 非彼 cc,我们来看看 cc 最后的原型是什么
我们看到 cc 最后指向的是 gcc,因此使用 cc 进行编译工作其实也是和使用 gcc 进行编译是一样的。那么上面的模式规则是谁来实现的呢?这个便是 makefile 中的隐式规则了。make 提供了生成目标文件的隐式规则,隐式规则会使用预定义变量完成编译工作;改变预定义变量将部分改变隐式规则的行为,当存在自定义规则时,不再使用隐式规则。当 make 发现目标的依赖不存在时,尝试通过依赖名逐一查找隐式规则,并且通过依赖名推导可能需要的源文件,如下
既然隐式编译这么强大,我们是不是就不用自己编写相关规则了呢?其实不是的,根据前辈们的经验总结。在实际的项目中,我们还是有必要禁止 makefile 中的隐式规则的,因为隐式规则有副作用。具体表现在:a> 编译行为难以控制,大量使用隐式规则可能产生意想不到的编译行为;b> 编译效率低下,make 从隐式规则和自定义规则中选择最终使用的规则。
那么我们下来来看看隐式规则链。当依赖的目标不存在时,make 会极力组合各种隐式规则对目标进行创建,进而产生意料之外的编译行为!如:需要名为 N.o 的目标:N.y --> N.c --> N.o。我们还是以代码为例来进行分析说明
main.c 源码
#include <stdio.h> extern void greeting(); int main() { greeting(); return 0; }
func.p 源码(这只是一个测试的代码,用的是 Pascal 语言)
unit Func; interface procedure Greeting(); attribute (name = 'greeting'); implementation procedure Greeting(); begin WriteLn('Hello, Pascal!'); end; end.
makefile 源码
app.out : main.o func.o $(CC) -lstdc++ -o $@ $^
那么我们此时想要用 func.c 实现某个功能,但是现在没有 func.c,所以编译时肯定会出错
我们看到 func.o 竟然会利用 func.p 来生成,不过最终还是出错了。出现这样的错误,我们是不是很纳闷呢?明明是没有对应的源文件,但是却报的是没有 pc 命令。这个便是 makefile 中的隐式规则了,那么 make 究竟提供了多少隐式规则?应如何查看查看隐式规则呢?查看隐式规则的方法是:查看所有的是 make -p;查看具体的规则是 make -p | grep "XXX"。下来我们来看看 make 中的隐式规则
因为所有的规则非常多,我们只截取了其中的一段,下来看看 %.o 对应的规则
我们看到它默认的是支持好多格式的,其中就包括 .c 和 .p 文件,因此它会将将我们之前的测试代码当成源文件进行编译了。那么我们应该如何避免它的隐式规则呢?在局部禁用的话,是直接在 makefile 中自定义规则或者在 makefile 中定义模式(如:%.o : %.p);全局禁用的话则使用 make -r。下来我们先来使用下局部禁用的方式,直接在 makefile 中定义模式,但是不做具体处理。
它直接就报错了,说没有相应的源文。我们再来看看使用全局禁用的方式
我们看到使用全局禁用的方式后,连 main.o 的文件也不能生成了。下来我们来说说后缀规则,它是旧式的“模式规则”,可以通过后缀描述的方式自定义规则。格式如下
后缀规则分为双后缀规则和单后缀规则。双后缀规则是指定义一对文件后缀(依赖文件后缀和目标文件后缀),如:.cpp.o <==> %.o : %.cpp;单后缀规则是指定义单个文件后缀(源文件后缀),如:.c <==> % : %.c。后缀规则有这么几个注意事项:1、后缀规则中不允许有依赖;2、后缀规则必须有命令,否则无意义;3、后缀规则将逐步被模式规则所取代。
下来我们还是以代码为例来进行分析说明,我们新建一个 func.c 文件用于说明问题
func.c 源码
#include <stdio.h> void greeting() { printf("void greeting : %s\n", "hello makefile!"); }
makefile 源码
app.out : main.o func.o $(CC) -lstdc++ -o $@ $^ .c.o : @echo "my suffix rule" $(CC) -o $@ -c $^ .c : @echo "my suffix rule" $(CC) -o $@ -c $^
我们来看看编译结果
我们看到已经正确实现了。不过在现在的工程项目中,我们一般都会摒弃掉后缀规则,采用的都是模式规则。通过对 makefile 中隐式规则的学习,总结如下:1、当多处出现同一目标的命令时,只有最后定义的命令才有效;2、make 提供了一系列的隐式规则可使用,当 makefile 中未定义相关规则时,将尝试使用隐式规则;3、隐式规则中可能使用 make 中的预定义变量,改变预定义变量可部分改变预定义规则的行为;4、隐式规则可能造成意想不到的编译行为,在实际工程项目中尽量不使用隐式规则;5、后缀规则是一种旧式的模式规则,它正逐步被模式规则所取代。
欢迎大家一起来学习 makefile,可以加我QQ:243343083。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。