我们来看看编译结果

        我们看到已经正确实现了字符串的打印，那么我们接下来在 func.h 源文件中想要改掉这个字符串为 Software 呢？试试看能不能修改成功

        我们看到在重新编译的时候，它并没有因为头文件的改变而改变，我们在 makefile 中又没有进行头文件的相关添加，改掉头文件中的内容肯定是不动的。下来我们在模式规则中加上头文件，在 %.c 后加上 func.h，再来看看编译结果

        我们看到直接添加之后，编译出错了。因为 -c 后面的目标中含有头文件，所以不能直接进行编译。我们可以只编译 %.o 后面的第一依赖 %.c，这样就不会去编译 func.h 头文件了，将下面的 $^ 改为 $< ，我们来看看效果

        我们看到已经正确改过来了。经过上面的实验，我们看到：头文件作为依赖条件出现于每个目标对应的规则中，当头文件改动时，任何源文件都将会被重新编译（编译低效）；当项目中头文件巨大时，makefile 将很难维护。那么我们的头脑中不禁会冒出这么个想法：通过命令对自动生成对头文件的依赖；将生成的依赖自动包含进 makefile 中；当头文件改动后，自动确认需要重新编译的文件。那么此时我们还需要知道一个命令，Linux 中的 sed 命令。sed 是一个流编辑器，用于流文本的修改（增、删、查、改）；它可用于流文本中的字符串替换，其字符串替换方式为：sed 's:src:des:g'，具体格式如下

        sed 同样也支持正则表达式，在 sed 中可以用正则表达式匹配替换目标，并且可以使用匹配的目标生成替换结果。格式如下

        下来我们以代码为例来看看 sed 命令是如何使用的

       再来看看 gcc 关键编译选项，获取目标的完整依赖关系：gcc -M test.c；获取目标的部分依赖关系：gcc -MM test.c。makefile 如下

        编译结果如下

        我们看到 -M 是获取了它的所有依赖关系，再来试试 -MM 呢

        我们看到 -MM 后，它只依赖与 main.c func.h。我们可以拆分目标的依赖，即将目标的完整依赖差分为多个部分依赖。格式如下

        我们来做个实验

        我们来打印看看目标 test 的依赖都有哪些，编译结果如下

        那么我们思考下：如何将 sed 和 gcc -MM 用于 makefile，并自动生成依赖关系呢？

        我们再来看看 makefile 中的 include 关键字，它类似于 C 语言中的 include，是将其它文件的内容原封不动的搬入当前文件。make 对 include 关键字的处理方式是在当前目录下搜索或指定搜索目标文件。如果搜索一成功，便将文件内容搬入当前 makefile 中；如果搜索失败，将会产生警告，以文件名作为目标查找并执行对应规则，当文件名对应的规则不存在时，最终产生错误。格式如下

        下来还是以代码为例来进行说明

        我们在第 3 行包含 test.txt，可是当前目录下并没有 test.txt，然后触发 test.txt 的规则。因而会打印出 test.txt，然后再创建 test.txt，我们来看看编译结果

        我们看到确实是创建了一个 test.txt 文件。那么在 makefile 中命令的执行是：1、规则中的每个命令默认是在一个新的进程中执行（Shell）；2、可以通过接续符（；）将多个命令组合成一个命令；3、组合的命令依次在同一个进程中被执行；4、set -e 指定发生错误后立即退出执行。那么我们看看下面的代码会实现想要的功能吗？

        我们来看看编译结果

        我们看到在当前目录下创建了目录，但是 subtest 目录却不是在 test 目录下创建的，这是怎么回事呢？在第一条命令执行时创建了目录 test，此时这个进程已经关闭了；在第二条命令执行时，执行的是另一个进程，虽然它已经进入到目录 test 中，但是随着这个进程的关闭，又回到了当前目录；第三个进程是重新创建了目录 subtest。那么如何解决这个问题呢？直接利用 set -e 和 接续符来解决

        看看编译结果

        那么我们之前思考问题的初步思路是：1、通过 gcc -MM 和 sed 得到 .dep 依赖文件（目标的部分依赖），技术点是规则中命令的连续执行；2、通过 include 指令包含所有的 .dep 依赖文件。技术点是当 .dep 依赖文件不存在时，使用规则自动生成。下面我们来看看解决方案是怎样的

        我们来看看编译结果

        我们先来分析下，在执行 make all 前，它先通过 include 包含 $(DEPS)，通过 $(DEPS) 触发模式规则，进而创建文件夹。我们看到在前面出现两个没有文件夹的信息，其实这条信息是可以隐藏的。我们在 include 前面加上 - 就 OK，来看看效果

        我们看到并没打印出前面的两条信息了。那么我们再来思考下：如何组织依赖文件相关的规则与源码编译相关的规则，进而形成功能完整的 makefile 程序呢？我们如何在 makefile 中组织 .dep 文件到指定目录呢？初步想法是当 include 发现 .dep 文件不存在时：1、通过规则和命令创建 deps 文件；2、将所有 .dep 文件创建到 deps 文件夹；3、.dep 文件中记录目标文件的依赖关系。

        我们下来看看初步的代码设计是怎样的

         我们来看看编译结果，是不是都将所有的 .dep 文件放入一个 deps 文件中

        我们看到已经实现效果了。我们仔细看看 make 有一个警告，说 main.dep 被修改了，也就是说 main.dep 被重新创建了。那么我们来分析下，为什么一些 .dep 依赖文件会被重复创建多次呢？deps 文件夹的时间属性会因为依赖文件创建而发生改变，make 发现 deps 文件夹比对应的目标更新，于是乎就触发相应的规则重新解析和执行命令。那么我们知道了原因，此时这个方案该如何优化呢？我们可以使用 ifeq 动态决定 .dep 目标的依赖，具体 makefile 如下

        我们再次编译看看

        我们看到它还是报了这样的错误，有可能是编译器的优化造成的。思路是正确的。下来我们来看看 include 的一些鲜为人知的秘密。

        A、 使用减号（-）不但关闭了 include 发出的警告，同时将关闭了错误；当错误发生时 make 将忽略这些错误！ 以代码为例来进行分析说明

        我们来编译看看

        我们看到不但发出警告，而且报错了。下来我们来在 include 前面加上 - 试试

        这样它也不报错了，直接就通过了，我们还以为 makefile 写的对着呢。这便是第一个暗黑操作。下来看看第二个暗黑操作

        B、如果 include 触发规则创建了文件，之后还会发生什么？以代码为例来进行分析说明

        看看编译结果

        我们进行直接 make 的时候，发现它输出的 this is other，并不是我们所期望的 this is all。这是为什么呢？因为在 include 的时候，直接将 test.txt 铺开在这，此时会触发规则。makefile 就变成了下面这样

        我们在直接 make 的时候，它默认执行的是第一个目标，因此便会输出 this is other，只有当我们 make all 的时候才会输出 this is all。这便是 include 的第二个暗黑操作了，下面继续看看第三个

        C、如果 include 包含的文件存在，之后会发生什么呢？以代码为例来进行分析说明

        在当前目录下创建一个 b.txt 文件，看看编译结果

        我们看到同样也执行了 test.txt 的相应的规则。看看下面这个 makefile 将会输出什么

        看看结果

        我们看到它最后输出的 all 的依赖是 c.txt，不应该觉得奇怪吗？我们明明在 all 后面没有依赖啊。再来看看生成的 test.txt 文件，它的内容是 all : c.txt，因此输出的结果是我们意想不到的。那么我们关于 include 便有了这几条总结：1、当目标文件不存在时，以文件名查找规则并执行；2、当目标文件不存在时且查找到的规则中创建了目标文件，将创建成功的目标文件包含进当前的 makefile 中；3、当目标文件存在，将目标文件包含进当前 makefile，以目标文件名查找是否有相应规则，YES 的话则比较规则的依赖关系来决定是否执行规则的命令，NO 的话则 NULL（无操作）。4、当目标文件存在且目标名对应的规则被执行，规则中的命令更新了目标文件，make 重新包含目标文件，替换之前包含的内容。目标文件未被更新，便是 NULL（无操作）。

        经过了这么多的知识点的探索，此时已经具备实现之前的想法的能力了。想要实现的具体格式如下

        下面我们就根据这个来编写相关的 makefile。

func.h 源码

func.c 源码