(一) rebuild build clean的实现
新知识点: 当一个目标的依赖是一个伪目标时,这个伪目标的规则一定会被执行。
贴实验代码
CC := gcc Target := helloworld.out $(Target) : func.o main.o $(CC) -o $(Target) main.o func.o main.o : main.c $(CC) -c main.c -o main.o func.o : func.c $(CC) -c func.c -o func.o .PHONY : rebuild clean build rebuild : clean build build : $(Target) # @echo "build" clean : # @echo "clean" rm *.o $(Target)
好了,现在不看这里的代码,自己实现一遍吧。
实操起来,发现不会?那肯定是对这里的代码没有嚼烂。
我们一起再来反复读读,做到彻底理解,力争能够一句话总结其中的道道。 原理释义,请看下图内文字:
比较底层的一个目标是Target,偏应用层的两个目标有rebuild、build,
把目标Target作为目标build的依赖, 目标build 就直接地具备了触发执行Target目标的能力。
把目标build作为目标rebuild的依赖,目标rebuild就间接地具备了触发执行Target目标的能力。
两句话总结其中的道道:
将各目标分层理解,哪些偏底层,哪些偏应用,梳理调用关系,从而知道各个目标直接或间接所具备的能力。
make软件就是这样直接或间接地一层层往底层去找依赖,最终的依赖一定是源文件,然后反推回来,因为源文件发生了变化,所有相关的目标都要被重新make,进而也执行了相关的目标下的所有命令。
(二)对目标的深入理解
实验一中说到一个点,这里再提一遍:
make软件总是认为目标是对应文件的
好,接下来进行本次实验的第二阶段:
问: 如果把这两处改为main2.o, 修改后的makefile和修改之前,在执行效果上,将有什么变化??
答:(答案见下图中文字)
修改前,目标main.o是存在的,本地的main.o也是存在的,
这时候还要看目标main.o的依赖main.c, 发现main.c也没被修改过,
所以make时,提示:Nothing to be done for 'build'
_