makefile多层目录实例（多级目录makefile，静态库）

本文目录

• 多级目录makefile，静态库
• Makefile.am 规则和实例详解
• 如何在makefile中指定头文件目录
• c文件在不同目录的情况makefile怎么写
• 高分求教！！！！：多级目录的makefile文件要怎么写在线等！！！！
• 根据提供的Linux 操作系统源码中Makefile 结构，分析在工程中多级目录中存在着多个makefile 时，编译的顺
• 根据提供的Linux操作系统源码中的Makefile结构，分析在工程多级目录中存在多个makefile文件时编译的顺序如
• Makefile详解

多级目录makefile，静态库

在lib 目录下编译需要生成动态库的文件，生成动态库，并安装到系统的标准库中，供程序调用。具体步骤如下：(1) 编写Makefile.am 文件AUTOMAKE_OPTIONS=foreignlib_LTLIBRARIES=libhello.lalibhello_la_SOURCES=test.c这里lib_LTLIBRARIES 的意思是生成的动态库，然后指定动态库依赖的源文件test.c ，若有多个源文件用空格隔开。(2) 在lib 目录下，用命令autoscan 产生configure.scan 文件,并改名为configure.in。 这里需加上宏AC_PROG_LIBTOOL，表示利用libtool 来自动生成动态库#configure.in# Process this file with autoconf to produce a configure script.AC_PREREQ(2.59)AC_INIT(hello,1.0, )AM_INIT_AUTOMAKEAC_CONFIG_SRCDIR()#AC_CONFIG_HEADER()# Checks for programs.AC_PROG_CC# Checks for header files.# Checks for typedefs, structures, and compiler characteristics.# Checks for library functions.AC_PROG_LIBTOOLAC_CONFIG_FILES()AC_OUTPUT(3) 执行命令aclocal、libtoolize -f -c 、autoconf、automake --add-missing、./configure、make、make install 将动态库安装到系统的标准库中，以供调用（一般为/usr/local/lib）。注：libtoolize 提供了一种标准的方式来将libtool 支持加入一个软件包，而GNU libtool 是一个通用库支持脚本，将使用动态库的复杂性隐藏在统一、可移植的接口中。4. 生成src 目录下的hello 可执行文件(1) 编写src/Makefile.am 文件AUTOMAKE_OPTIONS=foreignINCLUDES= -I../includebin_PROGRAMS=hellohello_SOURCES=hello.chello_LDADD=-lhello-ldir 指定编译时搜索库的路径。与静态库不同的是，创建动态库时不用指定库路径，编译器自动在标准库中查找libhello.so 文件。(2) 执行autoscan 生成configure.scan 文件，将它重命名为configure.in 并修改其内容。# configure.in# Process this file with autoconf to produce a configure script.AC_PREREQ(2.59)AC_INIT(hello,1.0, )AM_INIT_AUTOMAKEAC_CONFIG_SRCDIR()#AC_CONFIG_HEADER()# Checks for programs.AC_PROG_CC# Checks for header files.# Checks for typedefs, structures, and compiler characteristics.# Checks for library functions.AC_CONFIG_FILES()AC_OUTPUT(3) 在src 目录下编译并生成目标文件，执行命令aclocal、libtoolize -f -c 、autoconf、automake --add-missing、./configure、make，此时你一定会觉得，成功近在咫尺了。再执行目标文件./hello，结果却在你的意料之外：./hello: error while loading shared libraries: libhello.so.0 : cannot open shared object file:No such file or directory在执行目标文件的时候，Shell 找不到共享库的位置，需要我们手工载入库路径。5. shell 搜索动态库路径位置的两种方法(1) 使用命令导入动态库的路径，命令如下：export LD_LIBRARY_PATH=dir (如/usr/local/lib)(2) 修改/etc/ld.so.conf 文件，加入搜索路径，修改后用ldconfig 命令载入修改。将自己可能存放库文件的路径都加入到/etc/ld.so.conf 中是明智的选择 ^_^。添加方法也极其简单，将库文件的绝对路径直接写进去就OK 了，一行一个。例如：/usr/local/lib/usr/lib/lib需要注意的是：这种搜索路径的设置方式对于程序连接时的库（包括共享库和静态库）的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的。这是 因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文件 /etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件，不能直接，它是根据 /etc/ld.so.conf 中设置的搜索路径由/sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的（ldconfig 命令要以 root 权限执行）。因此，为了保证程序执行时对库的定位，在 /etc/ld.so.conf 中进行了库搜索路径的设置之后，还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache文件之后才可以。ldconfig ,简单的说，它的作用就是将/etc/ld.so.conf 列出的路径下的库文件 缓存到/etc/ld.so.cache 以供使用。因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf 增加新的库路径后，需要运行一下/sbin/ldconfig 使所有的库文件都被缓存到ld.so.cache 中，如果没做，即使库文件明明就在/usr/lib 下的，也是不会被使用的，结果编译过程中报错，缺少xxx 库，去查看发现明明就在那放着，搞的想大骂computer 蠢猪一个^_^。极力推荐使用这种方法！利用gcc 创建和使用动态库1. 用下面的命令将mylib.c 程序创建成一个动态库：gcc –fPIC –o mylib.o –c mylib.cgcc –shared –o libtt.so mylib.o-fPIC 作用于编译阶段，告诉编译器产生与位置无关代码(Position-Independent Code)，则产生的代码中，没有绝对地址，全部使用相对地址，故而代码可以被加载器加载到内存的任意位置，都可以正确的执行。这正是共享库所要求的，共享库被加载时，在内存的位置不是固定的。-shared 作用于链接阶段，实际传递给链接器ld，让其添加作为共享库所需要的额外描述信息，去除共享库所不需的信息。也可以直接使用下面一条命令：gcc –fPIC –shared –o libtt.so mylib.c2. 将动态库拷贝到linux 的标准库中，usr/local/lib 或者/usr/lib 或者/lib:cp libttt.so /usr/local/lib3. 编译src 目录下的源程序时，指定动态库文件的目录，调用动态库中的函数gcc –o test test.c /usr/lib/libttt.so4. 设置shell 动态库搜索路径，运行生成的可执行文件。

Makefile.am 规则和实例详解

编写Linux C 程序的时候，自己来写Makefile着实的让人很头疼，如果是简单的项目自己写写也就罢了，但是如果遇到大项目自己写Makefile，那是要弄死人的，所以最近在研究Autotools工具自动生成Makefile，在用到autotools工具生成Makefile的时候，还是有一部分需要自己来完成的，那就是Makefile.am文件。项目中写在源文件里的Makefile.am是一种比我们了解的Makefile更高层次的编译规则，它可以和编写的configure.in（了解更多configure.in的规则请阅读《 configure.ac (configure.in)详解 》）文件一起通过调用automake命令，来生成Makefile.in文件，然后再调用./configure，将Makefile.in文件自动的生成Makefile文件。所以Makefile.am文件是要自动生成Makefile必不可少的元素，下面鹏博客就来和大家着重的学习下Makefile.am的写法和规则。 先来说下Makefile.am中常见的文件编译类型，详细的编译类型和全局变量鹏博客会在下面在图表中列出： PROGRAMS           表示可执行文件 SOURCES              表示源文件 HEADERS              头文件。 LIBRARIES             表示库文件 LTLIBRARIES         这也是表示库文件，前面的LT表示libtool。 DATA                       数据文件，不能执行。 SCRIPTS                脚本文件，这个可以被用于执行。如：example_SCRIPTS，如果用这样的话，需要我们自己定义安装目录下的example目录，很容易的，往下看。 一、基本写法 下面就直接引入一个例子进行详细讲解，如下： AUTOMAKE_OPTIONS = foreign bin_PROGRAMS = client client_SOURCES = key.c connect.c client.c main.c session.c hash.c client_CPPFLAGS = -DCONFIG_DIR=\“$(sysconfdir)\” -DLIBRARY_DIR=\”$(pkglibdir)\” client_LDFLAGS = -export-dynamic -lmemcached noinst_HEADERS = client.h INCLUDES = -I/usr/local/libmemcached/include/ client_LDADD = $(top_builddir)/sx/libsession.la \ $(top_builddir)/util/libutil.la 上面就是一个Makefile.am示例文件，这个文件是用于生成client可执行应用程序，引用了两个静态库和MC等动态库的连接。 先来看个图表一（列出了可执行文件、静态库、头文件和数据文件，四种书写Makefile.am文件个一般格式。）： 对于可执行文件和静态库类型，如果只想编译，不想安装到系统中，可以用noinst_PROGRAMS代替bin_PROGRAMS，noinst_LIBRARIES代替lib_LIBRARIES。以此类推。 根据这个图表一来分析下具体内容： AUTOMAKE_OPTIONS ：这个是用来设定automake的选项。automake主要是帮助开发GNU软件的人员维护软件套件，一般在执行automake时会检查目录下是否存在标准GNU套件中应具备的文件档案，例如NEWS、AUTHOR、ChangeLog等，设成foreign时，automake会改用一般软件套件标准来检查，而gnu是缺省设置，该级别下将尽可能地检查包是否服从GNU标准，gnits是严格标准，不推荐。 bin_PROGRAMS ：表示要生成的可执行应用程序文件，这里的bin表示可执行文件在安装时需要被安装到系统中，如果只是想编译。不想被安装到系统中，可以用noinst_PROGRAMS来代替。 那么整个第一行 bin_PROGRAMS=client 详细表示什么意思那，解释如下： PROGRAMS知道这是一个可执行文件。 client表示编译的目标文件。 bin表示目录文件被安装到系统的目录。 如程序和图片所示，包括头文件，静态库的定义等等都是这种形式，如lib_LIBRARIES=util，表示将util库安装到lib目录下。 继续解释文件内容： client_SOURCES ：表示生成可执行应用程序所用的所有源文件源文件，多个就空格隔开，我们注意到client_是由前面的bin_PROGRAMS指定的，如果前面是生成example, 那么这里也就变成example_SOURCES，其它的规则类似标识也是一样。 client_CPPFLAGS ：这个和我们写Makefile的时候意思是一样的，都表示C语言的预处理器参数，这里指定了DCONFIG_DIR，以后在程序中，就可以直接使用CONFIG_DIR,不要把这个和另一个CFLAGS混淆，后者表示编译器参数。 client_LDFLAGS ：表示在连接时所需要的库文件选项标识。这个也就是对应一些如-l,-shared等选项。 noinst_HEADERS ：表示该头文件只是参加可执行文件的编译，而不用安装到安装目录下。如果需要安装到系统中，可以用include_HEADERS来代替。 INCLUDES ：表示连接时所需要的头文件。 client_LDADD ：表示连接时所需要的库文件,这里表示需要两个库文件的支持，下面会看到这个库文件又是怎么用Makefile.am文件后成的。 如图表二： 全局变量 ，可能有人注意到文件中的$(top_builddir)等全局变量，其实这个是Makefile.am系统定义的一个基本路径变量，表示生成目标文件的最上层目录，如果这个Makefile.am文件变成其它的Makefile.am文件，那么这个就表示其它的目录，而不是这个当前目录。我们还可以使用$(top_srcdir)，这个表示工程的最顶层目录，其实也是第一个Makefile.am的入口目录，因为Makefile.am文件可以被递归性的调用。 如图表三：（在Makefile.am中尽量使用相对路径，系统预定义了两个基本路径） $(sysconfdir) ：在系统安装工具的时候，我们经常能遇到配置安装路径的命令，如：./configure –prefix=/install/apache  其实在调用这个之后，就定义了一个变量$(prefix), 表示安装的路径，如果没有指定安装的路径，会被安装到默认的路径，一般都是/usr/local。在定义$(prefix)，还有一些预定义好的目录,其实这一些定义都可以在顶层的Makefile文件中可以看到，如下面一些值： bindir = $(prefix)/bin。 libdir = $(prefix)/lib。 datadir=$(prefix)/share。 sysconfdir=$(prefix)/etc。 includedir=$(prefix)/include。 这些量还可以用于定义其它目录，例如我想 将client.h安装到include/client目录下 ，这样写Makefile.am文件： clientincludedir=$(includedir)/client clientinclude_HEADERS=$(top_srcdir)/client/client.h 这就达到了我的目的，相当于定义了一个安装类型，这种安装类型是将文件安装到include/client目录下。 我们自己也可以 定义新的安装目录下的路径 ，如我在应用中简单定义的： devicedir = ${prefix}/device device_DATA = package 这样的话，package文件会作为数据文件安装到device目录之下，这样一个可执行文件就定义好了。注意，这也相当于定义了一种安装类型：devicedir，所以你想怎么安装就怎么安装，后面的XXXXXdir，dir是固定不变的。 二、配置静态库 下面我们来说下编译静态库和编译动态库，我们说下静态库，下面这个例子比较简单。直接指定 XXXX_LTLIBRARIES或者XXXX_LIBRARIES就可以了。同样如果不需要安装到系统，将XXXX换成noinst就可以。 一般推荐使用libtool库编译目标，因为automake包含libtool，这对于跨平台可移植的库来说，是一个很好的事情。 看例子如下： noinst_LTLIBRARIES = libutil.la oinst_HEADERS = inaddr.h util.h compat.h pool.h xhash.h url.h device.h ibutil_la_SOURCES = access.c config.c datetime.c hex.c inaddr.c log.c device.c pool.c rate.c sha1.c stanza.c str.c xhash.c ibutil_la_LIBADD = @LDFLAGS@ 第一行的noinst_LTLIBRARIES，这里要注意的是LTLIBRARIES，另外还有LIBRARIES，两个都表示库文件。前者表示libtool库，用法上基本是一样的。如果需要安装到系统中的话，用lib_LTLIBRARIES。 .la 为libtool自动生成的一些共享库，vi查看，主要记录了一些配置信息。可以用如下命令查看*.la文件的格式   $file *.la .a 为静态库,是好多个.o合在一起,用于静态连接 如果想编译 .a 文件，那么上面的配置就改成如下结果： noinst_LTLIBRARIES = libutil.a oinst_HEADERS = inaddr.h util.h compat.h pool.h xhash.h url.h device.h ibutil_a_SOURCES = access.c config.c datetime.c hex.c inaddr.c log.c device.c pool.c rate.c sha1.c stanza.c str.c xhash.c ibutil_a_LIBADD = @LDFLAGS@ 注意：静态库编译连接时需要其它的库的话，采用XXXX_LIBADD选项，而不是前面的XXXX_LDADD。编译静态库是比较简单的，因为直接可以指定其类型。 三、配置动态库 如果想要编译XXX.so动态库文件，需要用到_PROGRAMS类型，有一个关于安装路径的问题，如果希望将动态库安装到lib目录下，按照前面所说的，只需要写成lib_PROGRAMS就可以了，lib表示安装的路径，但是automake不允许这样直接定义，所以可以采用下面的办法，同样是将动态库安装到lib目录下： projectlibdir=$(libdir)//新建一个目录，就是该目录就是lib目录 projectlib_PROGRAMS=project.so project_so_SOURCES=xxx.C project_so_LDFLAGS=-shared -fpic//GCC编译动态库的选项 这个动态库的编译写法是鹏博客网上总结的，希望有要的人自己来验证下。 四、SUBDIRS功能用法 SUBDIRS 这是一个很重要的词，我们前面生成了一个目标文件，但是一个大型的工程项目是由许多个可执行文件和库文件组成，也就是包含多个目录，每个目录下都有用于生成该目录下的目标文件的Makefile.am文件，但顶层目录是如何调用，才能使下面各个目录分别生成自己的目标文件呢？就是SUBDIRS关键词的用法了。 看一下我的工程项目，这是顶层的Makefile.am文件 EXTRA_DIST = Doxyfile.in README.win32 README.protocol contrib UPGRADE devicedir = ${prefix}/device device_DATA = package SUBDIRS = etc man ifUSE_LIBSUBST SUBDIRS += subst endif SUBDIRS += tools io sessions util client dispatch server hash storage sms SUBDIRS表示在处理目录之前，要递归处理哪些子目录，要注意处理的顺序。比如配置中的client对sessions和utils这两上目标文件有依赖关系，就在client之前需要处理这两个目标文件。 EXTRA_DIST ：将哪些文件一起打包。 五、打包处理 Automake会自动的打包 ，自动打包的内容如下： 所有程序的源文件。 所有子目录里的的Makefile.am文件。 Makefile.am中包含的文件。 ./configure所要读取的文件。 EXTRA_DIST所指定的文件。 dist和nodist指定的文件，也可将其中一个源文件指定为不打包： 例如： nodist_client_SOURCES = client.c 六、最后 这里是鹏博客总结的一些比较实用的Makefile.am的写法和规则，看完了这篇文章已经可以很详细的理解这个文件的内容，写起来也应该不会陌生，但automake还有许多其他的规则需要掌握，鹏博客将会继续全面的总结关于autotools 的一些规则和写法，希望对大家有用处。也欢迎大家指出问题，帮我完善这个博客，希望大家支持！ automake的Makefile.am Makefile.am写法

如何在makefile中指定头文件目录

1、首先在目录HelloMakefile下，创建测试文件main.c。

2、然后运行autoscan,生成autoscan.log，configure.scan，还有main.c。

3、接着将configure.scan文件重命名为configure.in，命令如下：mv configure.scan configure.in。

4、然后修改configure.in中的内容。

5、然后执行aclocal命令，生成aclocal.m4  autom4te.cache两个文件。

6、最后执行autoconf命令，生成重要的configure.in文件。

c文件在不同目录的情况makefile怎么写

c文件在不同目录的情况makefile怎么写假设有下面几个c++文件：wherewhen.h wherewhen.c countdown.h countdown.c 包含了math.h， 需要连接库文件 main.c 主函数， main.c 包含了两个头文件 wherewhen.h and countdown.h 1、第一种编译方法：g++ -Wall -g wherewhen.c countdown.c main.c -lm -o myprogram 生成可执行文件myprogram 2、第二中编译方法， 分别编译各个文件：g++ -Wall -g -c wherewhen.c g++ -Wall -g -c countdown.c g++ -Wall -g -c main.c g++ -g wherewhen.o countdown.o main.o -lm -o myprogram

高分求教！！！！：多级目录的makefile文件要怎么写在线等！！！！

在m目录下新建makefile文件内容：EXE = targetOBJECT = a.o b.o main.oCFLAGS = -I a/ -I b/VPATH = a b$(EXE):$(OBJECT) gcc -o $(EXE) $(OBJECT) rm -f $(OBJECT)main.o : a.h b.ha.o : a.hb.o : b.h.PHONY : cleanclean: rm -f $(OBJECT) rm -f $(EXE)总文件目录m:a/ b/ main.c makefile target*m/a:a.c a.hm/b:b.c b.h在m目录下执行make命令 生成可执行文件target ps：你的a.c文件内容少了一行#include《stdio.h》#include"a.h" void a(){ printf("hello! \n"); } b.c文件内容也少了一行#include《stdio.h》#include"b.h"void b(){ printf("everyone. \n"); }

根据提供的Linux 操作系统源码中Makefile 结构，分析在工程中多级目录中存在着多个makefile 时，编译的顺

多级目录的编译顺序也是有Makefile控制的, 如下这个例子(3个子目录, 一个Makefile), 子目录的编译顺序由这个Makefile控制.sub_a sub_b sub_c Makefile

根据提供的Linux操作系统源码中的Makefile结构，分析在工程多级目录中存在多个makefile文件时编译的顺序如

书上56页有讲make的递归过程指的是：在Makefile中使用“make”作为一个命令来执行本身或者其它makefile文件的过程。递归调用在一个存在有多级子目录的项目中非常有用。例如，当前目录下存在一个“subdir”子目录，在这个子目录中有描述此目录编译规则的makefile文件，在执行make时需要从上层目录（当前目录）开始并完成它所有子目录的编译。那么在当前目录下可以使用这样一个规则来实现对这个子目录的编译：subsystem:cd subdir && $(MAKE) 其等价于规则： subsystem:$(MAKE) -C subdir

Makefile详解

make 命令执行时，需要根据一些规则来决定按照怎么样的方式去 编译和链接程序 ，这些规则就由 makefile 文件所指定。如果我们 makefile 文件写的足够好，make 命令会自动地根据当前的文件修改的情况来确定哪些文件需要重编译，从而自己编译所需要的文件和链接目标程序。

首先，本文将给出一个makefile文件的示例，以便大家能有一个直观感受，这个例子来源于 GNU的make使用手册 。在这个例子中，我们的工程有8个c文件，和3个头文件，我们要写一个makefile来告诉make命令如何编译和链接这几个文件。例子如下：

这个例子里 make 的编码规则如下：

a. 如果这个工程没有编译过，那么我们的所有c文件都要编译并被链接。 b. 如果这个工程的某几个c文件被修改，那么我们只编译被修改的c文件，并链接目标程序。 c. 如果这个工程的头文件被改变了，那么我们需要编译引用了这几个头文件的c文件，并链接目标程序。

在详细拆解上一节的 Makefile 之前，先来看下 Makefile 的基本范式。

target可以是一个 1) object file(可执行文件) ，2) 可执行文件 ，还可以是个3) label(标签) ，关于标签这个特性，在后面的 伪目标 章节还会有叙述。

prerequisites 就是，要生成那个target所需要的文件或是目标。 command 也就是 make 需要执行的命令，可以是任意的 shell 命令。

这是一个文件的依赖关系，也就是说，target 这一个或多个的目标文件依赖于 prerequisites 中的文件，其生成规则定义在 command 中。同时， prerequisites 中如果有一个以上的文件比target文件要新的话， command 所定义的命令就会被执行。这就是 Makefile 的规则，也是 Makefile 中 最核心 的内容。

有了这些规则后，再来分析上面的例子。在这个 makefile 中，目标文件(target)包含：

依赖文件(prerequisites)就是冒号后面的那些 .c 文件和 .h 文件。每一个 .o 文件都有一组依赖文件，而这些 .o 文件又是执行文件 edit 的依赖文件。

在定义好依赖关系后，后续的那一行定义了如何生成目标文件的系统命令， 一定要以一个tab键作为开头 。 make 会比较 targets 文件和 prerequisites 文件的修改日期，如果 prerequisites 文件的日期要比targets文件的日期要新，或者 target 不存在的话，那么，make就会执行后续定义的命令。

我们可以把这个内容保存在名字为 makefile 或 Makefile 的文件中，然后在该目录下直接输入命令 make 就可以生成可执行文件edit。如果要删除执行文件和所有的中间目标文件，那么，只要简单地执行一下 make clean 就可以了。 注：反斜线(\)是换行符的意思，这样比较便于阅读。

这里要说明一点的是， clean 不是一个文件，它只不过是一个动作名字，有点像C语言中的 lable 一样，其冒号后什么也没有，那么，make就不会去找它的依赖性，也就不会自动执行其后所定义的命令。要执行其后的命令(不仅用于 clean，其他 lable 同样适用)，就要在 make 命令后显式指出这个 lable 的名字。这样的方法非常有用， 我们可以在一个 makefile 中定义不用的编译或是和编译无关的命令，比如程序的打包，程序的备份 ，等等。

在默认的方式下，也就是我们只输入make命令。那么，

这就是整个 make 的依赖性，make 会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么make就会直接退出，并报错，而对于所定义的命令的错误，或是编译不成功，这些都不在 make 职责范围内。

通过上述分析，我们知道，像 clean 这种，没有被第一个目标文件直接或间接关联，那么它后面所定义的命令将不会被自动执行，不过，我们可以显示要 make 执行。即命令 make clean ，以此来清除所有的目标文件，以便重编译。

在上面的例子中可以看到，后缀为 .o 的一大串文件名写了两次，这样比较费时费力，而且如果文件有所增减，要修改的地方也非常多，对以后的维护造成困难。在这种情形下，我们可以在Makefile里使用变量代替这一大串依赖文件，这里变量的使用方式基本类似于shell脚本里变量的使用方法。

我们可以在makefile一开始就这样定义：

那么接下来我们就可以很方便地在我们的Makefile中以 $(objects) 的方式来使用这个变量了，于是如果有新的 .o 文件加入，我们只需简单地修改一下 objects 变量就可以了。

GNU 的 make 很强大，它可以自动推导文件以及文件依赖关系后面的命令，于是我们就没必要去在每一个 .o 文件后都写上类似的命令。因为，我们的make会自动识别，并自己推导命令。

只要make看到一个 .o 文件，它就会自动的把 .c 文件加在依赖关系中，如果make找到一个 FILENAME.o ，那么 FILENAME.c ，就会是 FILENAME.o 的依赖文件。并且 cc -c FILENAME.c 也会被推导出来，于是，我们的makefile 再也不用写得这么复杂。我们的新makefile就可以这么写了。

这种方法，也就是make的**。上面文件内容中，“.PHONY”表示，clean是个伪目标文件。