搜索
这个手册翻译整理:徐海兵,先表示一些尊敬.“本人在工作之余，花了18个多月时间完成对“infomake”的翻译整理，完成这个中文版手册”,工夫不负有心人.链接器将.o文件中使用的函数和其它.o或者库文件中的相关符号进行合并，对所有文件中的符号进行重新安排（重定位），并链接系统相关文件（程序启动文件等）最终生成可执行程序。Linux中，共享库文件格式通常为“ELF”格式。共享库已经具备了可执行条件。模块中各个成员的地址（变量引用和函数调用）都是相对地址。使用此共享库的程序在运行时，共享库被动态加载到内存并和主程序在内存中进行连接。多个可执行程序可共享库文件的代码段（多个程序可以共享的使用库中的某一个模块，共享代码，不共享数据）。另外共享库的成员对象可被执行（由libdl.so提供支持）。在make读取Makefile以后会建立一个编译过程的描述数据库。此数据库中记录了所有各个文件之间的相互关系，以及它们的关系描述(要是我能看到这个数据库，就能使用程序trace，你知道一个大型的project的makefile有多复杂)当使用make工具进行编译时，工程中以下几种文件在执行make时将会被编译（重新编译）：1.所有的源文件没有被编译过，则对各个C源文件进行编译并进行链接，生成最后的可执行程序；2.每一个在上次执行make之后修改过的C源代码文件在本次执行make时将会被重新编译；3.头文件在上一次执行make之后被修改。则所有包含此头文件的C源文件在本次执行make时将会被重新编译。(这就是为什么头文件修改后，很多文件都会被重新compile的原因)首先书写时，可以将一个较长行使用反斜线（\）来分解为多行，这样可以使我们的Makefile书写清晰、容易阅读理解。但需要注意：反斜线之后不能有空格（这也是大家最容易犯的错误，错误比较隐蔽）编译.c源文件规则的命令可以不用明确给出。这是因为make本身存在一个默认的规则，能够自动完成对.c文件的编译并生成对应的.o文件。它执行命令“cc-c”来编译.c源文件。对一个目标文件是“N.o”，倚赖文件是“N.c”的规则，完全可以省略其规则的命令行，而由make自身决定使用默认命令。此默认规则称为make的隐含规则。书写规则建议的方式是：单目标，多依赖。就是说尽量要做到一个规则中只存在一个目标文件，可有多个依赖文件。尽量避免多目标，单依赖的方式。这样后期维护也会非常方便，而且Makefile会更清晰、明了。在这个Makefile中，根据依赖而不是目标对规则进行分组(Wrong!)。上例的Makefile就可以这样来实现：#sampleMakefileobjects=main.okbd.ocommand.odisplay.o\insert.osearch.ofiles.outils.oedit:$(objects)cc-oedit$(objects)$(objects):defs.hkbd.ocommand.ofiles.o:command.hdisplay.oinsert.osearch.ofiles.o:buffer.h例子中头文件“defs.h”作为所有.o文件的依赖文件。其它两个头文件作为其对应规则的目标中所列举的所有.o文件的依赖文件。但是这种风格的Makefile并不值得我们借鉴。问题在于：同时把多个目标文件的依赖放在同一个规则中进行描述（一个规则中含有多个目标文件），这样导致规则定义不明了，比较混乱。建议大家不要在Makefile中采用这种方式了书写。否则后期维护将会是一件非常痛苦的事情。“include”指示符告诉make暂停读取当前的Makefile，而转去读取“include”指定的一个或者多个文件，完成以后再继续当前Makefile的读取。通常指示符“include”用在以下场合：1.有多个不同的程序，由不同目录下的几个独立的Makefile来描述其重建规则。它们需要使用一组通用的变量定义或者模式规则。2.当根据源文件自动产生依赖文件时；我们可以将自动产生的依赖关系保存在另外一个文件中，主Makefile使用指示符“include”包含这些文件。这样的做法比直接在主Makefile中追加依赖文件的方法要明智的多。其它版本的make已经使用这种方式来处理。(我想看看这方面的例子)当在这些目录下都没有找到“include”指定的文件时，make将会提示一个包含文件未找到的告警提示，但是不会立刻退出。而是继续处理Makefile的后续内容。当完成读取整个Makefile后，make将试图使用规则来创建通过指示符“include”指定的但未找到的文件，当不能创建它时（没有创建这个文件的规则），make将提示致命错误并退出。通常我们在Makefile中可使用“-include”来代替“include”，来忽略由于包含文件不存在或者无法创建时的错误提示（“-”的意思是告诉make，忽略此操作的错误。make继续执行）。Makefile中符号“$”有特殊的含义（表示变量或者函数的引用），在规则中需要使用符号“$”的地方，需要书写两个连续的（“$$”）。Maekfile中表示文件名时可使用通配符。可使用的通配符有：“*”、“?”和“[…]”。在Makefile中这些统配符并不是可以用在任何地方，Makefile中统配符可以出现在以下两种场合：1.可以用在规则的目标、依赖中，make在读取Makefile时会自动对其进行匹配处理（通配符展开）；2.可出现在规则的命令中，通配符的通配处理是在shell在执行此命令时完成的。除这两种情况之外的其它上下文中，不能直接使用通配符。而是需要通过函数“wildcard”来实现。比如变量定义中使用的通配符不会被统配处理（因此在变量定义中不能使用通配符，否则在某些情况下会出现非预期的结果，下一小节将会详细讨论）。在Makefile有这样一个变量定义：“objects=*.o”。它表示变量“objects”的值是字符串“*.o”（并不是期望的空格分开的.o文件列表）。当需要变量“objects”代表所有.o文件列表示，需要使用函数“wildcard”（objects=$(wildcar*.o)）。在规则中，通配符会被自动展开。但在变量的定义和函数引用时，通配符将失效。这种情况下如果需要通配符有效，就需要使用函数“wildcard”，它的用法是：$(wildcardPATTERN...)。在Makefile中，它被展开为已经存在的、使用空格分开的、匹配此模式的所有文件列表。如果不存在任何符合此模式的文件，函数会忽略模式字符并返回空。一般我们可以使用“$(wildcard*.c)”来获取工作目录下的所有的.c文件列表。复杂一些用法；可以使用“$(patsubst%.c,%.o,$(wildcard*.c))”，首先使用“wildcard”函数获取工作目录下的.c文件列表；之后将列表中所有文件名的后缀.c替换为.o。这样我们就可以得到在当前目录可生成的.o文件列表。因此在一个目录下可以使用如下内容的Makefile来将工作目录下的所有的.c文件进行编译并最后连接成为一个可执行文件：#sampleMakefileobjects:=$(patsubst%.c,%.o,$(wildcard*.c))foo:$(objects)cc-ofoo$(objects)使用伪目标有两点原因：1.避免在我们的Makefile中定义的只执行命令的目标（此目标的目的为了执行执行一些列命令，而不需要创建这个目标）和工作目录下的实际文件出现名字冲突。2.提高执行make时的效率，特别是对于一个大型的工程来说，编译的效率也许你同样关心。如:在make的并行和递归执行过程中。此情况下一般会存在一个变量，定义为所有需要make的子目录。对多个目录进行make的实现方式可以是：在一个规则的命令行中使用shell循环来完成。如下：SUBDIRS=foobarbazsubdirs:fordirin$(SUBDIRS);do\$(MAKE)-C$$dir;\done但这种实现方法存在以下几个问题:1.当子目录执行make出现错误时，make不会退出。就是说，在对某一个目录执行make失败以后，会继续对其他的目录进行make。在最终执行失败的情况下，我们很难根据错误提示定位出具体是在那个目录下执行make时发生错误。这样给问题定位造成了很大的困难。为了解决这个问题，可以在命令行部分加入错误监测，在命令执行错误后主动退出。不幸的是，如果在执行make时使用了“-k”选项，此方式将失效。2.另外一个问题就是使用这种shell的循环方式时，没有用到make对目录的并行处理功能，由于规则的命令是一条完整的shell命令，不能被并行处理。有了伪目标之后，我们可以用它来克服以上实现方式所存在的两个问题。SUBDIRS=foobarbaz.PHONY:subdirs$(SUBDIRS)subdirs:$(SUBDIRS)$(SUBDIRS):$(MAKE)-C$@foo:baz上边的实现中有一个没有命令行的规则“foo:baz”，此规则用来限制子目录的make顺序。它的作用是限制同步目录“foo”和“baz”的make过程（在处理“foo”目录之前，需要等待“baz”目录处理完成）。提醒大家：在书写一个并行执行make的Makefile时，目录的处理顺序是需要特别注意的。（在broadcom的project中，clean的工作就是用了SUBDIRS类似的用法：SUBDIRS_APP=$(SUBDIRS_BROADCOM)$(SUBDIRS_OPENSOURCE)$(SUBDIRS_ALPHASOURCE)SUBDIRS=$(foreachdir,$(SUBDIRS_APP),$(shellif[-d$(dir)];thenecho$(dir);fi))而后面subdirs:$(patsubset%,_dir_%,$(SUBDIRS))$(patsubset%,_dir_%,$(SUBDIRS)):$(MAKE)-C$(patsubset_dir_%,%,$@)$(TGT)）make存在一个内嵌隐含变量“RM”，它被定义为：“RM=rm–f”。静态模式规则是这样一个规则：规则存在多个目标，并且不同的目标可以根据目标文件的名字来自动构造出依赖文件。静态模式规则比多目标规则更通用，它不需要多个目标具有相同的依赖。但是静态模式规则中的依赖文件必须是相类似的而不是完全相同的。首先，我们来看一下静态模式规则的基本语法：TARGETS...:TARGET-PATTERN:PREREQ-PATTERNS...COMMANDS首先在目标模式和依赖模式中，一般需要包含模式字符“%”。在目标模式（TAGET-PATTERN）中“%”可以匹配目标文件的任何部分，模式字符“%”匹配的部分就是“茎”。目标文件和目标模式的其余部分必须精确的匹配。看一个例子：目标“foo.o”符合模式“%.o”，其“茎”为“foo”。而目标“foo.c”和“foo.out”就不符合此目标模式。每一个目标的依赖文件是使用此目标的“茎”代替依赖模式（PREREQ-PATTERNS）中的模式字符“%”而得到。例如：上边的例子中依赖模式（PREREQ-PATTERNS）为“%.c”，那么使用“茎”“foo”替代依赖模式中的“%”得到的依赖文件就是“foo.c”。需要明确的一点是：在模式规则的依赖列表中使用不包含模式字符“%”也是合法的。代表这个文件是所有目标的依赖文件。我们来看一个例子，它根据相应的.c文件来编译生成“foo.o”和“bar.o”文件：objects=foo.obar.oall:$(objects)$(objects):%.o:%.c$(CC)-c$(CFLAGS)$-o$@如果存在一个文件列表，其中一部分符合某一种模式而另外一部分符合另外一种模式，这种情况下我们可以使用“filter”函数来对这个文件列