target ... : prerequisites ...
command
...
...
target
可以是一个object file（目标文件），也可以是一个执行文件，还可以是一个标签（label）。对于标签这种特性，在后续的”伪目标”章节中会有叙述。
prerequisites
生成该target所依赖的文件和/或target
command
该target要执行的命令（任意的shell命令）
这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说:prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。
edit : main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
cc -o edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
把所有的 .o文件都用 objects代替了,如果要使用这些被定义的 .o文件，需要使用 $(objects)代替，如果不加上 $()可能有其他的文件也叫 objects，这样就可以区分了
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edit $(objects)
比如看到 main.o,会自动推导出需要 main.c或者 main.cpp文件，（推导不出头文件，需自己添加），那么如果是.c文件，会自动推导出需要添加 cc -c命令
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : defs.h
kbd.o : defs.h command.h
command.o : defs.h command.h
display.o : defs.h buffer.h
insert.o : defs.h buffer.h
search.o : defs.h buffer.h
files.o : defs.h buffer.h command.h
utils.o : defs.h
.PHONY : clean
clean :
rm edit $(objects)
这种方法，也就是make的”隐晦规则”。上面文件内容中， .PHONY 表示 clean 是个伪目标文件。
既然我们的make可以自动推导命令，那么我看到那堆 .o和 .h的依赖就有点不爽，那么多的重复的 .h，能不能把其收拢起来，好吧，没有问题，这个对于make来说很容易，谁叫它提供了自动推导命令和文件的功能呢？来看看最新风格的makefile吧。
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
$(objects) : defs.h
kbd.o command.o files.o : command.h
display.o insert.o search.o files.o : buffer.h
.PHONY : clean
clean :
rm edit $(objects)
这种风格，让我们的makefile变得很简单，但我们的文件依赖关系就显得有点凌乱了。鱼和熊掌不可兼得。还看你的喜好了。我是不喜欢这种风格的，一是文件的依赖关系看不清楚，二是如果文件一多，要加入几个新的 .o文件，那就理不清楚了。
每个Makefile中都应该写一个清空目标文件（ .o和执行文件）的规则，这不仅便于重编译，也很利于保持文件的清洁。这是一个”修养”（呵呵，还记得我的《编程修养》吗）。一般的风格都是：
clean:
rm edit $(objects)
更为稳健的做法是：
.PHONY : clean
clean :
-rm edit $(objects)
前面说过， .PHONY 表示 clean 是一个”伪目标”。而在 rm 命令前面加了一个小减号的意思就是，也许某些文件出现问题，但不要管，继续做后面的事。当然， clean 的规则不要放在文件的开头，不然，这就会变成make的默认目标，相信谁也不愿意这样。不成文的规矩是——”clean从来都是放在文件的最后”。
在Makefile使用 include 关键字可以把别的Makefile包含进来，这很像C语言的 #include ，被包含的文件会原模原样的放在当前文件的包含位置。 include 的语法是 include <filename></filename>， filename 可以是当前操作系统Shell的文件模式（可以包含路径和通配符）。
在 include前面可以有一些空字符，但是绝不能是 Tab 键开始。 include 和 <filename></filename> 可以用一个或多个空格隔开。举个例子，你有这样几个Makefile： a.mk、 b.mk 、 c.mk ，还有一个文件叫 foo.make ，以及一个变量 $(bar) ，其包含了 e.mk 和 f.mk ，那么，下面的语句：
include foo.make *.mk $(bar)
等价于：
include foo.make a.mk b.mk c.mk e.mk f.mk
make命令开始时，会找寻 include 所指出的其它Makefile，并把其内容安置在当前的位置。就好像C/C++的 #include 指令一样。如果文件都没有指定绝对路径或是相对路径的话，make会在当前目录下首先寻找，如果当前目录下没有找到，那么，make还会在下面的几个目录下找：
如果make执行时，有 -I 或 --include-dir 参数，那么make就会在这个参数所指定的目录下去寻找。
如果目录 <prefix>/include</prefix> （一般是： /usr/local/bin 或 /usr/include）存在的话，make也会去找。
如果有文件没有找到的话，make会生成一条警告信息，但不会马上出现致命错误。它会继续载入其它的文件，一旦完成makefile的读取，make会再重试这些没有找到，或是不能读取的文件，如果还是不行，make才会出现一条致命信息。如果你想让make不理那些无法读取的文件，而继续执行，你可以在 include前加一个减号 -。如：
-include <filename></filename>
其表示，无论 include过程中出现什么错误，都不要报错继续执行。和其它版本make兼容的相关命令是 sinclude，其作用和这一个是一样的。
如果你的当前环境中定义了环境变量 MAKEFILES ，那么，make会把这个变量中的值做一个类似于 include 的动作。这个变量中的值是其它的Makefile，用空格分隔。只是，它和 include 不同的是，从这个环境变量中引入的Makefile的”目标”不会起作用，如果环境变量中定义的文件发现错误，make也会不理。
但是在这里我还是建议不要使用这个环境变量，因为只要这个变量一被定义，那么当你使用make时，所有的Makefile都会受到它的影响，这绝不是你想看到的。在这里提这个事，只是为了告诉大家，也许有时候你的Makefile出现了怪事，那么你可以看看当前环境中有没有定义这个变量。
GNU的make工作时的执行步骤如下：（想来其它的make也是类似）
读入所有的Makefile。
读入被include的其它Makefile。
初始化文件中的变量。
推导隐晦规则，并分析所有规则。
为所有的目标文件创建依赖关系链。
根据依赖关系，决定哪些目标要重新生成。
执行生成命令。
1-5步为第一个阶段，6-7为第二个阶段。第一个阶段中，如果定义的变量被使用了，那么，make会把其展开在使用的位置。但make并不会完全马上展开，make使用的是拖延战术，如果变量出现在依赖关系的规则中，那么仅当这条依赖被决定要使用了，变量才会在其内部展开。
当然，这个工作方式你不一定要清楚，但是知道这个方式你也会对make更为熟悉。有了这个基础，后续部分也就容易看懂了。
Original: https://www.cnblogs.com/ys-wang/p/16562749.html
Author: 森森成长日记
Title: Makefile
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/578636/
转载文章受原作者版权保护。转载请注明原作者出处！