Autobook的翻译草稿3

jasonCSH

//*************************************************************

译序

初学linux系统，感觉linux底下的编译，链接程序真的很麻烦。
因此想到了用Autoconf等工具。找到了Autobook这本好书。
也不知道有没有人翻译过这本书。
该书由女友Ellen翻译，在此对她表示感谢。
该书原文请参考 http://sources.redhat.com/autobook/...tobook_toc.html
如果翻译时有什么错误请
Ellengut2002@yahoo.com或者jasongut2002@126.com

转载请保留译序,3x.

//--------------------------------


2.3        配置的发展
  Cygnus `configure' script 和original GCC `configure' script必须更新以适应它们支持的Unix新版本。也就是说，随着Unix新版本的不时出现，使用Cygnus `configure' script 和original GCC `configure' script的软件包就时常处于过时状态。尽管对开发者而言，增加新系统版本的支持并不困难，但是软件包用户却不能轻易完成这项任务。
   Imake在通常的使用过程中也存在着同样的问题。尽管用户可以为特定系统创建并配置Imake，但是这种做法并不常用。事实上，像X window系统这样使用Imake的软件包是与针对特定Unix版本的详细配置信息一起装载的。
    由于Metaconfig和Autoconf都使用特性测试，它们产生的脚本通常不用修改就能在新的Unix版本上运行。因此，它们更容易使用并且适应性更强，而Autoconf也被广泛的应用。
    1994年，, David MacKenzie将Cygnus `configure' script和original GCC `configure' script的特性融合到Autoconf中。其中包括对交互编译和使用针对特定系统的头文件的支持。
    GCC至此也改用Autoconf来替代GCC `configure' script。使用GCC `configure' script的程序也大多用Autoconf进行了改编。人们不再用Cygnus `configure' script编写新的程序。
    metaconfig程序至今仍被用于配置Perl和其他很少的程序。Imake仍被用于配置X window系统。但是，这些工具一般不再用于新的软件包。
2.4        Automake的发展
   到1994年，Autoconf已经是处理不同Unix版本之间差异的固定框架。但是程序开发者仍不得不编写庞大的`Makefile.in'文件才能使用Autoconf。由Autoconf产生的`configure'脚本将Makefile.in'文件转化为make程序使用的 Makefile。
    `Makefile.in'文件必须对如何创建程序进行描述。而在Imake`中具有'Makefile.in功能的'Imakefile却只需描述创建程序时使用了哪些源文件。当Imake`产生一个'Makefile时，它会自动增加关于如何创建程序的规则。BSD make程序后来的版本也包含了创建程序的规则。
  既然大多程序的创建方式是雷同的，'Makefile.in文件中将存在大量的重复。GNU项目开发了一个相当复杂的`Makefile's标准集。因此，很容易产生细节错误。
   上述因素都促成了Automake的开发。像autoconf一样，Automake是由开发者运行的程序。开发者编写以`Makefile.am'为名的文件；这些文件使用比普通的`Makefile.in '更简单的语法。Automake读取 Makefile.am'文件并产生`Makefile.in文件。这样，由autoconf产生的脚本将这些`Makefile.in文件转化为Makefile's。
    如同Imake和BSD make一样，Makefile.am'文件只需描述用于创建程序的文件。Automake在产生`Makefile.in文件时会自动增加所需规则。Automake还会增加GNU `Makefile'要求的任何规则。
     1994年，David MacKenzie编写了Automake的第一个版本。Tom Tromey于1995年对此进行了完全的改写。
2.5         Libtool的发展
   随着时间的发展，Unix 系统增加了对共享库的支持。
    传统的库，即静态库，是与程序的映象相连接的。也就是说，使用静态库的每个程序包括了磁碟上二进制程序中的部分或全部库。
    共享库是独立的文件。使用共享库的程序并不包含库；它仅仅包含库的名字。许多程序能使用同一个共享库。
    使用共享库降低了对磁盘空间的要求。既然通常情况下系统能在许多程序中共享同一个共享库的可执行实例，使用共享库也降低了运行时对交换空间的要求。另外，通过更新磁盘上的一个共享库文件就能改正错误，而不必重建使用库的所有程序。第一个Unix的共享库应用是在AT&T发行的System V第三版。这一想法很快被其他的Unix销售商采纳。如SunOS, HP-UX, AIX, 和 Digital Unix。不幸的是，各个共享库在创建、使用以及它所支持的具体特征方面都是不同的。
    很自然地，包含库并作为源代码散布的软件包想创建它们自己的共享库。几个不同的共享库实例被写在Autoconf/Automake框架上。
    1996年, Gordon Matzigkeit开始创建软件包Libtool。Libtool是shell脚本集合。这些shell脚本集合是用于处理不同版本的共享库在不同系统中使用时的差异。Libtool与Automake紧密相连，而且不能独立使用。
    随着时间的推移，Libtool已经能够支持更多的Unix版本，并能提供使共享库特性标准化的接口。
2.6 Microsoft Windows
    1995年，Microsoft发行了Windows 95。Windows 95很快成为全世界广泛应用的操作系统。Autoconf 和 Libtool在编写时是为了支持不同Unix版本之间的移植，但是它们提供的框架结构也能支持移植到windows。这样使得程序可以支持来自同一源代码库的Unix 和Windows。
   Unix shell是对Autoconf 和 Libtool的关键要求。GNU bash shell作为Cygwin project（最早由Steve Chamberlain编写）的一部分被移植到Windows。Cygwin project执行Windows中基本的Unix API。这样 Unix程序才可以被直接移植。
    一旦shell 和Unix make程序（也是由Cygwin提供的）可以使用，Autoconf和Libtool就可以通过使用Cygwin接口或Microsoft的Visual C++直接支持Windows。这需要处理像不同系统使用不同文件扩展名以及共享库的另一特性集之类的细节。Ian Lance Taylor于1998年编写了的Automake第一个版本。Automake也被移植到Windows.它要求安装Perl。

wide288

这篇好，讲到了 makefile.in makefile.am 两个文件。