本文转自http://blog.chinaunix.net/uid-20608849-id-360294.html
笔者在写程序的时候会遇到这样的烦恼：一个项目中可能会有很多个应用程序，而新建一个应用程序则所有的Makefile都要重写一遍，虽然可以部分的粘帖复制，但还是感觉应该找到更好的解决途径；另外当一个应用程序中包含多个文件夹时通常要在每个目录下创建一个Makefile，当有数十个文件夹时，要创建如此多的Makefile也是不胜其烦。那么为什么不用automake呢，诚然，对于一个很大的工程来说使用automake是一个很好的选择，但是对于一个新手或者一个小的应用程序来说使用它有两个弊端：或多或少阻碍对于Makefile的理解和书写；没有必要，编译出了差错难以从全局把握。
在某次项目中，发现了一个比较好的Makefile，所有生成的.o .d文件均位于build下，而源码位于src下，条理清晰，无论添加多少文件夹，只需要一个Makefile就可以搞定。但是很快发现一个问题，当src下不同文件夹下有重名的文件.c时，事情很糟糕，后者会覆盖前者的.o文件。那么开始考虑以下问题：
只是用一个Makefile如何动态改变.o生成路径呢？比如一个源码目录为src, 其中包含两个目录a和b，分别又包含a.c 和b.c，在src目录下有一Makefile，a和b中没有单独的Makefile。
- src/a/a.c
- src/b/b.c
- src/main.c
如何写Makefile使临时文件.o .d(之所以需要生成.d，是因为头文件依赖，后面会提到)等自动生成到
- build/a/a.o 和a.d
- build/b/b.o 和b.d
- build/main.o 和main.d
通常可以做到所有临时文件都生成到build下，如下规则：
- ......
- TARGETMAIN = testmk
- OBJECTDIR = build
- VPATH = $(shell ls -AxR ./src|grep ":"|grep -v "\.svn"|tr -d ':')
- SOURCEDIRS = $(VPATH)
- # search source file in the current dirs
- SOURCES = $(foreach subdir,$(SOURCEDIRS),$(wildcard $(subdir)/*.c))
- SRCOBJS = $(patsubst %.c,%.o,$(SOURCES))
- BASE_FILES = $(notdir $(TMSRCOBJS))
- BUILDOBJS = $(BASE_FILES:%=$(OBJECTDIR)/%)
- all:$(TARGETMAIN)
- $(TARGETMAIN) :$(BUILDOBJS)
- $(CC) $(CFLAGS) -o $@ -c $<
- @$(STRIP) --strip-unneeded $(TARGETMAIN)
- ......
- $(OBJECTDIR)/%.o: %.c $(DEPS_DIR)
- @$(CC) $(CPPFLAGS) $(CFLAGS) -o $@ -c $<
根据上面的问题分析，SOURCEDIRS中为src中所有的目录（包括./src），SOURCES中保存了所有的相对当前路径的.c文件，比如./src/a/a.c。SRCOBJS使用函数patsubst将SOURCES中所有.c文件的后缀替换为.o。$(TARGETMAIN)也即testmk依赖于$(BUILDOBJS)，BUILDOBJS变量由SRCOBJS生成，只是所有的src路径被subst函数替换为了build，比如./src/a/a.o，则替换为了./build/a.o，我们看到在匹配$(OBJECTDIR)/%.o: %.c规则的时候，%将代表文件名main, a，b等，也即./build/a.o依赖于a.c。
$@变量代表了生成的目标文件，由目标./build/a/a.o决定，$<为对应于依赖，由%.c决定，也即a.c，那么Makefile如何知道a.c对应src/a/a.c呢，这和VPATH变量有关。如果定义了VPATH这个变量，那么make就会在当当前目录找不到的情况下，到VPATH指定的目录中去查找文件了。
最终build下会生成a.o，b.o和main.o，并且链接为testmk可执行文件。
这是我们最终通用makefile的雏形，但是会当src下不同文件夹有重名文件的.c时，生成.o就会冲突，那么如何解决呢，我们看到$@和$<分别代表了目标集和依赖集，而目标集由%决定，.c由VPATH决定，那么我们只要改变%或者$@和$<变量就可以，$@和$<被称为自动变量，但是并不意味着我们不能动态改变它。这里给出最终的解决方案：
- #声明伪目标，防止Makefile去生成all等
- .PHONY = all install clean
- #定义路径变量，所有.c文件和所有非公开的.h应该放在src下，所有需要的.a文件放在lib
- #下，所有公开的.h（比如生成库文件的时候）或者多个.c公用的.h放在include文件夹下
- #global directory defined
- TOPDIR = $(shell pwd)
- SRCDIR = $(TOPDIR)/src
- LIBDIR = $(TOPDIR)/lib
- OBJECTDIR = $(TOPDIR)/build
- INCLUDEDIR = $(TOPDIR)/include
- #定义交叉编译环境变量，当需要编译arm/mips等平台应用程序/库的时候修改它
- #cross compile tools defined
- CROSS_COMPILE =
- AS = $(CROSS_COMPILE)as
- LD = $(CROSS_COMPILE)ld
- CC = $(CROSS_COMPILE)gcc
- CPP = $(CC) -E
- AR = $(CROSS_COMPILE)ar
- NM = $(CROSS_COMPILE)nm
- STRIP = $(CROSS_COMPILE)strip
- RANLIB = $(CROSS_COMPILE)ranlib
- #本机相关的命令，一般无需修改
- #local host tools defined
- CP := cp
- RM := rm
- MKDIR := mkdir
- SED := sed
- FIND := find
- MKDIR := mkdir
- XARGS := xargs
- #目标名称，这里我们给出了三种常用的目标格式：目标文件，静态库和共享库
- #target name
- TARGETMAIN = testmk
- TARGETLIBS = libmk.a
- TARGETSLIBS = libmk.so
- #所有源码文件的路径被放入SOURCEDIRS，所有.c源码文件（含路径）放入SOURCES
- #.c .o and .d files defined
- VPATH = $(shell ls -AxR $(SRCDIR)|grep ":"|grep -v "\.svn"|tr -d ':')
- SOURCEDIRS = $(VPATH)
- SOURCES = $(foreach subdir,$(SOURCEDIRS),$(wildcard $(subdir)/*.c))
- #所有目标文件.o（含路径）放入BUILDOBJS，注意它们的路径已经是build了。
- SRCOBJS = $(patsubst %.c,%.o,$(SOURCES))
- BUILDOBJS = $(subst $(SRCDIR),$(OBJECTDIR),$(SRCOBJS))
- #所有.d依赖文件放入DEPS
- DEPS = $(patsubst %.o,%.d,$(BUILDOBJS))
- #注意-MD，是为了生成.d文件后，构造对.h的依赖
- #external include file define
- CFLAGS = -O2 -Wall -MD $(foreach dir,$(INCLUDEDIR),-I$(dir))
- ARFLAGS = rc
- #special parameters for app
- CFLAGS +=
- #LDFLAGS指明所有-llibxx，libxx.a应该放到lib下，当然也可以添加.so。Xlinker是为了
- #在提供多个.a时，未知它们之间的依赖顺序时，自动查找依赖顺序
- #c file compile parameters and linked libraries
- CPPFLAGS =
- LDFLAGS =
- XLDFLAGS = -Xlinker "-(" $(LDFLAGS) -Xlinker "-)"
- LDLIBS += -L $(LIBDIR)
- #如果要生成.a或者.so，那么不要将main函数所在的.c放入src。另外添加$(TARGETLIBS)
- #或$(TARGETSLIBS)到all中
- #defaut target:compile the currrent dir file and sub dir
- all: $(TARGETMAIN)
- #for .h header files dependence
- -include $(DEPS)
- $(TARGETMAIN) :$(BUILDOBJS)
- @$(CC) $(subst $(SRCDIR),$(OBJECTDIR),$^) $(CPPFLAGS) $(CFLAGS) $(XLDFLAGS) -o $@ $(LDLIBS)
- @$(STRIP) --strip-unneeded $(TARGETMAIN)
- $(TARGETLIBS) :$(BUILDOBJS)
- @$(AR) $(ARFLAGS) $@ $(BUILDOBJS)
- @$(RANLIB) $@
- $(TARGETSLIBS) :$(BUILDOBJS)
- @$(CC) -shared $(subst $(SRCDIR),$(OBJECTDIR),$^) $(CPPFLAGS) $(CFLAGS) $(XLDFLAGS) -o $@ $(LDLIBS)
- #这里是Makefile的核心，根据%中的内容，查找src路径下对应的.c，注意到$@和$<自动
- #变量的取值，首先查看路径build/xx是否存在，不存在则创建，然后我们尝试将$@中的src
- #替换为build，这样所有的.o和.d都将被创建到对应的build下了。
- $(OBJECTDIR)%.o: $(SRCDIR)%.c
- @[ ! -d $(dir $(subst $(SRCDIR),$(OBJECTDIR),$@)) ] & $(MKDIR) -p $(dir $(subst $(SRCDIR),$(OBJECTDIR),$@))
- @$(CC) $(CPPFLAGS) $(CFLAGS) -o $(subst $(SRCDIR),$(OBJECTDIR),$@) -c $<
- #添加安装的路径
- intall:
- clean:
- @$(FIND) $(OBJECTDIR) -name "*.o" -o -name "*.d" | $(XARGS) $(RM) -f
- @$(RM) -f $(TARGETMAIN) $(TARGETLIBS) $(TARGETSLIBS)
经测试，完全满足了要求，虽然不是完美无缺，但是对于通常的工程项目，是绰绰有余了，欢迎大家指正，以便改善。
另外对于Makefile的理解，个人认为可以分成几个部分：依赖关系，自定义变量和自动变量以及Makefile提供的相关函数。理解了它们，对写出结构良好，通用性强的Makefile会有大的帮助，虽然现在有了automake，但是研究一下Makefile的写法还是有收获的。
附件testmk.rar中提供了一个完整的测试程序，目录如下：
- |-- build
- |-- include
- | `-- hello.h
- |-- lib
- |-- Makefile
- `-- src
- |-- a
- | `-- a.c
- |-- b
- | `-- b.c
- `-- main.c
- 6 directories, 5 files
在linux下解压开后运行命令一下命令，可以根据需要定制Makefile。
- #make // 当前目录下生成testmk
- #make libmk.a // 当前目录下生成libmk.a
- #make libmk.so // 当前目录下生成libmk.so
参考资料：
- 跟我一起写Makefile（通俗易懂，易于理解）
- GNU make中文手册（内容很全，是对GNU makefile手册的完全翻译，做手册参考）
思考：
根据Makefile的依赖原理，似乎应该使用一个树类型的结构，a依赖b,c等，b又依赖其他的文件，但是不能反方向依赖（否则为死循环），但是d可以同时依赖b,c，所以不是简单的树形结构，应该是一个图，另外依赖是有方向性的，所以应该是一个有向图结构的实现，不知道对不对？
--------------------------------------------------------------------------------分割线--------------------------------------------------------------------------------------
文件testCmakefile和testCPPmakefile分别是真的c和c++的两个实例，两者makefile内容主要的区别就是编译器gcc和g++，以及后缀.c和.cpp。其他的地方都不用修改。