GNUMake中文手册v38学习.docVIP

这个手册翻译整理: 徐海兵, 先表示一些尊敬. “本人在工作之余，花了18个多月时间完成对“info make”的翻译整理，完成这个中文版手册”, 工夫不负有心人. 链接器将.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就可以这样来实现： #sample Makefileobjects = 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 例子中头文件“defs.h”作为所有.o文件的依赖文件。其它两个头文件作为其对应规则的目标中所列举的所有.o文件的依赖文件。 但是这种风格的Makefile并不值得我们借鉴。问题在于：同时把多个目标文件的依赖放在同一个规则中进行描述（一个规则中含有多个目标文件），这样导致规则定义不明了，比较混乱。建议大家不要在Makefile中采用这种方式了书写。否则后期维护将会是一件非常痛苦的事情。 “include”指示符告诉make暂停读取当前的Makefile，而转去读取“include”指定的一个或者多个文件，完成以后再继续当前Makefile的读取。通常指示符“include”用在以下场合： 1. 有多个不同的程序，由不同目录下的几个独立的Makefile来描述其重建规则。它们需要使用一组通用的变量定义或者模式规则。 2. 当根据源文件自动产生依赖文件时；我们可以将自动产生的依赖关系保存在另外一个文件中，主Makefile使用指示符“include”包含这些文件。这 样的做法比直接在主Makefile中追加依赖文件的方法要明智的多。其它版本的make已经使用这种方式来处理。(我想看看这方面的例子)当 在这些目录下都没有找到“include”指定的文件时，make将会提示一个包含文件未找到的告警提示，但是不会立 刻退出。而是继续处理Makefile的后续内容。当完成读取整个Ma