GNU Make 及Makefile的编写.pdfVIP

GNU Make 及Makefile 的编写(一) 2007-07-27 14:14 0) 介绍 ~~~~~~~~~~~~~~~ 本文将首先介绍为什么要将你的Ｃ源代码分离成几个合理的独立档案，什么时 候需 要分，怎么才能分的好。然后将会告诉你 GNU Make 怎样使你的编译和连 接步骤自动化。 对于其它 Make 工具的用户来说，虽然在用其它类似工具时要 做适当的调整，本文的内容 仍然是非常有用的。如果对你自己的编程工具有怀 疑，可以实际的试一试，但请先阅读用 户手册。 1) 多文件项目 ~~~~~~~~~~~~~~~~~~~~~~ 1.1 为什么使用它们? 首先，多文件项目的好处在那里呢？ 它们看起来把事情弄的复杂无比。又要 header 文件，又要 extern 声明，而且如果 需要查找一个文件，你要在更多的文件里搜索。 但其实我们有很有力的理由支持我们把一个项目分解成小块。当你改 动一行代码， 编译器需要全部重新编译来生成一个新的可执行文件。 但如果你的项目是分开在几个小文 件里，当你改动其中一个文件的时 候，别的源文件的目标文件(object files) 已经存在，所以 没有什么 原因去重新编译它们。你所需要做的只是重现编译被改动过的那个文 件，然后重 新连接所有的目标文件罢了。在大型的项目中，这意味着 从很长的（几分钟到几小时）重 新编译缩短为十几，二十几秒的简单 调整。 只要通过基本的规划，将一个项目分解成多个小文件可使你更加容易 的找到一段代 码。很简单，你根据代码的作用把你的代码分解到不同 的文件里。当你要看一段代码时， 你可以准确的知道在那个文件中去 寻找它。 从很多目标文件生成一个程序包 (Library) 比从一个单一的大目标文件 生成要好的多。 当然实际上这是否真是一个优势则是由你所用的系统 来决定的。但是当使用 gcc/ld (一个 GNU C 编译／连接器) 把一个程 序包连接到一个程序时，在连接的过程中，它会尝试不去 连接没有使 用到的部分。但它每次只能从程序包中把一个完整的目标文件排除在 外。因此 如果你参考一个程序包中某一个目标档中任何一个符号的话， 那么这个目标文件整个都会 被连接进来。要是一个程序包被非常充分 的分解了的话，那么经连接后，得到的可执行文 件会比从一个大目标 文件组成的程序包连接得到的文件小得多。 又因为你的程序是很模块化的，文件之间的共享部分被减到最少，那 就有很多好处 ——可以很容易的追踪到臭虫，这些模块经常是可以用 在其它的项目里的，同时别人也可 以更容易的理解你的一段代码是干 什么的。当然此外还有许多别的好处„„ 1.2 何时分解你的项目 很明显，把任何东西都分解是不合理的。象“世界，你们好”这样的 简单程序根本 就不能分，因为实在也没什么可分的。把用于测试用的 小程序分解也是没什么意思的。但 一般来说，当分解项目有助于布局、 发展和易读性的时候，我都会采取它。在大多数的情 况下，这都是适 用的。（所谓“世界，你们好”，既 hello world ，只是一个介 绍一种编程 语言时惯用的范例程序，它会在屏幕上显示一行 hello world 。是最简单的程序。） 如果你需要开发一个相当大的项目，在开始前，应该考虑一下你将 如何实现它，并 且生成几个文件（用适当的名字）来放你的代码。 当然，在你的项目开发的过程中，你可 以建立新的文件，但如果你 这么做的话，说明你可能改变了当初的想法，你应该想想是否 需要 对整体结构也进行相应的调整。 对于中型的项目，你当然也可以采用上述技巧，但你也可以就那么开 始输入你的代 码，当你的码多到难以管理的时候再把它们分解成不同 的档案。但以我的经验来说，开始 时在脑子里形成一个大概的方案， 并且尽量遵从它，或在开发过程中，随着程序的需要而 修改，会使开 发变得更加容易。 1.3 怎样分解项目 先说明，这完全是我个人的意见，你可以（也许你真的会？）用别的 方式来做。这 会触动到有关编码风格的问题，而大家从来就没有停止 过在这个问题上的争论。在这里我 只是给出我自己喜欢的做法（同时 也给出这么做的原因）：