(一) 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'
_