Auto-book-中文版

1目录1介绍2历史3如何运行configure和make4Makefile介绍5一个最小的GNUAutotools项目6写configure.in7GNUAutomake介绍8启动9一个小型GNUAutotools项目10GNULibtool介绍11使用GNULibtooll和configure.in，Makefile.am12一个大型的GNUAutotools项目13分发软件包14安装和卸载被配置的包15编写和GNUAutotools可移植的C16编写和GNUAutotools可移植的C++17动态加载18使用GNUlibltdl19高级GNUAutomake用法20一个复杂的GNUAutotools项目21M422编写可移植的BourneShell23编写Autoconf的新宏24移植现有的库到GNUAutotools25在CygnusCygwin中使用Autotools26和GNUAutotools交叉编译A安装GNUAutotoolsB平台C生成文件依赖关系DAutoconf宏参考EOPL索引这是XXX第一次转载别人的文章，只因今天在网上找autobook的中文版，竟找不到，且发现很多人和我遇到同样的问题。于是决定将此书翻译，以满足广大linux初学者学习automake的愿望。已有人将前几章译过，在此发扬不重复劳动精神借用之，不久就会将autobook完整翻译。因本人水平有限，难免有出错之处，还望各位不吝赐教，若有能力者强烈建议读原文，在此下载。2——-本篇为转载内容，原作者文章请看这里——–1.简介Autoconf、Automake和Libtool这三个软件包可以让你的软件具有更好的可移植性并简化其构建的过程──尤其是在其他人的系统上。软件的可移植性和高效的构建系统是现代软件工程实践中非常重要的方面。现在，人们通常都希望软件能在不止一个平台上运行，因为硬件的限制有可能会改变对平台的选择，新的客户可能在使用不同的系统，而你所使用的操作系统提供商也可能在新版本中引入与之前不兼容的变化。此外，能够让软件构建过程更简单且不容易出错的工作也是非常有价值的。Autoconf这个工具可以在编译软件包前执行一系列测试，发现系统的特性，而你的源码可以去适应不同系统的差别。通过这种方式，可以让你的软件包具有更好的可移植性。Automake是产生’Makefile’──描述要构建什么──的工具，它遵从了很多的标准。Automake极大地简化了描述软件包结构及追踪源码间依赖关系的过程。Libtool是编译器和连接器的命令行接口，利用它可以方便地产生具有可移植性的静态库和动态链接库。1.1本书涉及什么本书是关于Autoconf、Automake和Libtool的教程，以下将它们简称为GNUAutotools。GNU手册分别对这三种工具进行详细的阐述，但迄今为止，还没有哪本指南描述过它们如何共同工作的。近年来，这些工具得到了发展，对相关问题很了解的贡献者们做出了相应的设计，但是描述原理的文件却几乎没有。在阅读例子时，可能有人会问为什么Autoconf的宏使用以下的shell结构：iftestx$var=xbar;thenechoyes1&5fi而不是更简单的if[$var=bar];thenechoyes1&5fi诸如此类问题的答案都记录在了本书中。1.2本书不涉及什么3本书不是一本Autoconf、Automake或Libtool的权威参考，否则书中将充斥过时的信息。譬如本书并不对由Autoconf提供的每一个预先定义的宏进行描述。相反，本书将帮助你理解你所遇到的任何宏，并影响你处理软件可移植性和软件包创建的方式。以上工具的GNU手册可以作为参考书。本书对相关概念只作简单介绍而不是详细地解释它们。本书会介绍如何编写’Makefile’和Bourneshell脚本，但是你必须参考其他工具书以便熟悉这些主题。1.3本书为谁而作软件开发者，系统管理员和技术管理员很可能对关于GNUAutotools的书感兴趣。软件开发者，特别是自由项目的开发者会认为了解如何使用这些工具是十分有价值的，因为GNUAutotools在自由软件社区中正变得越来越流行。室内项目的开发者如用这些工具也会受益非浅。系统管理者能从这些工具的使用知识中受益。因为系统管理员的通常任务就是编译和安装使用GNUAutotools框架的软件包。偶尔，特性测试也会产生错误的结果而导致编译错误或程序异常。通常稍微hacking一下就可以编译软件包了，但是知道解决问题的正确方法能够帮助软件包的维护者。最后，书中的讨论将使技术管理员对软件可移植性的复杂本质和创建大型项目的过程有进一步的了解。1.4本书是如何组织的与任何一本好的教程一样，本书首先解释简单的概念，然后在这些基础知识上再进一步延伸至高层次的主题。本书的第一部分将阐述这些工具的发展及其存在的原因。第二部分则是本书的主要内容。首先解释’Makefile’和configurationtriplets之类的概念。此后的章节将逐一介绍各个工具及如何使用它们来处理不同规模的项目。如果用C和C++语言编写的程序十分粗糙的话，该程序将不可移植。第14和15章将分别指导如何用C和C++语言编写可移植程序。第三部分提供的信息是你在其他任何参考书中都没法找到的。因为该部分是根据大量应用这些工具的实际经验编写而成的。其中有章节是关于一些高级但又十分重要的概念，如m4宏处理器及如何写可移植Bourneshell的脚本。第23章将概述如何把一个现存的软件包移植到GNUAutotools框架。许多开发者会对该章内容十分感兴趣，因为在交叉编译环境中使用GNUAutotools创建软件包是最令人困惑的。第25章将就此作出解释。2.历史4本章我们就书中工具的发展历史进行简要阐述。你不必为了使用这些工具而去了解历史，但是了解这些工具的发展过程将有助于了解为何它们以目前的方式运作。此外，在这样一本书中，我们有必要感谢原创作者及其灵感来源，并对他们所做的贡献作一番解释。2.1Unix的多样性在数种所讨论的程序中，最早开发出来的是Autoconf。它的发展是由Unix操作系统的历史决定的。贝尔实验室的DennisRitchie和KenThompson于1969编写了最早版本的Unix。在上世纪七十年代，尽管贝尔实验室并不被允许商业化地出售Unix，但是它确实以较低的价格将Unix卖给了一些大学。加州大学伯克利分校在原Unix的源码上做了改进，并形成了BSD版的Unix。上世纪八十年代早期，AT&T签定允许他们商业化地出售Unix的协议，Unix的第一个AT&T版本是SystemIII。八十年代随着Unix越来越流行，其他一些公司对原有的Unix进行修改而形成了他们自己的版本。例如，SunMicrosystems的SunOS、DigitalEquipmentCorporation的Ultrix以及HewlettPackard的HP-UX。尽管Unix的各个版本在本质上是相似的，各版本之间还是有区别的。它们的头文件集和系统库所提供的函数还是有些细微的差别，而在中断处理和作业控制等方面存在的差别则更大。然而POSIX的出现则消除了其中的一些差别。但是POSIX在一些领域中又引入了新的特性，从而导致了更多的版本。同样，不同系统采用不同时期的POSIX标准，也导致了更多的差异。所有这些差异给作为源代码散布的程序带来了问题。即便是像memcpy这样简单的函数也不是任何系统都提供的；BSD系统库提供与之类似的功能bcopy，但是参数的次序是相反的。要想使程序在不同版本的Unix都能运行，程序的作者若就必须熟悉各版本之间的具体差别。他们还需要注意这些差别在各版本中是如何体现的，因为它们虽然都遵循POSIX标准，但是各自又引入了新的各不相同的特性。虽然通常情况下可以用#ifdef来确认特定的系统和版本，但是人们越来越难以知道哪个版本具有哪些特性。因此，人们需要更系统的方法来处理不同版本间的差异。2.2第一个配置程序到1992为止，人们已经开发了四个系统来帮助实现源代码的移植：Metaconfigprogram，作者是LarryWall、HarlanStenn和RaphaelManfredi。5Cygnus’configure’脚本，作者是K.RichardPixley，以及原由的GCC’configure’脚本，作者是RichardStallman。两者十分相似，且其开发者经常交流。GCC是GNUCompilerCollection,也就是以前的GNUC编译器。GNUAutoconf软件包，作者是DavidMacKenzie。Imake，XWindow系统的一部分以上系统都将构建程序分成两步：配置和构建。并且在进行构建时都使用了标准的Unixmake程序。Make程序从’Makefile’中读取一系列规则，并用这些规则创建程序。配置步骤所做的工作是产生’Makefile’文件，也可能还产生其它可能在构建过程中使用到的文件。Metaconfig和Autoconf都用特性测试来测试系统的兼容性。它们用Bourneshell脚本（所有Unix版本都以不同形式支持Bourneshell脚本）运行不同的测试以确定系统支持的内容。Cygnus的’configure’脚本和原先的GCC’configure’脚本也是Bourneshell脚本。它们靠小的配置文件得到每个系统的变量，包括头文件和’Makefilse’片段。在早期版本中，编译程序的使用者必须告诉脚本该程序是为哪种系统构造的；后来PerBothner对其进行了改进，他编写的shell脚本能根据标准Unixuname程序和其它信息确定系统类型。Imake是可移植的C程序。它可以被定制以用于特定的系统，并作为软件包构建的一部分来运行。但更常见的情况是，Imake和软件包一起发行，其中的软件包包含了被支持的系统所需的所有配置信息。Metaconfig和Autoconf是程序作者使用的程序。它们产生的shell脚本将与程序的源代码一起散布。而想要构建程序的用户在程序要运行的系统上执行这个shell脚本，从而为源代码产生相应系统的配置。Cygnus和GCC’configure’脚本,还有imake,对于用户和开发人员使用来说没有分别。Cygnus和GCC’configure’脚本支持跨平台开发,两者都支持内建一个可以在不同的平台上编译的跨平台的编译器，用来编译程序。Autoconf,Metaconfig和Imake没有这些功能(他们最后加入了Autoconf)；它们只支持在它们各自工作的平台上编译程序。TMetaconfig生成的脚本是默认交互的:它们在执行时向用户询问。这样可以使它们知道难于测试出的平台的特征，来确定平台下的执行方式。Cygnus和GCC’configure’脚本,及autoconf生成的脚本,imake程序不是交互式的:它们自己决定任何事。使用Autoconf时，包开发者一般会写命令行的参数选项来决定它们不能检测出的功能，有时会要求用户在执行‘configure’脚本后写一个头文件。62.3配置的发展Cygnus的’configure’脚本和原先的GCC’configure’脚本必须更新以适应它们支持的Unix新版本。也就是说，随着Unix新版本的不时出现，使用它们的软件包就时常处于过时状态。尽管对开发者而言，增加新系统版本的支持并不困难，但是软件包用户却不能轻易完成这项任务。Imake在通常的使用过程中也存在着同样的问题。尽管用户可以为特定系统创建并配置Imake，但是这种做法并不常用。事实上，像Xwindow系统这样使用Imake的软件包是与针对特定Unix版本的详细配置信息一起发布的。由于Metaconfig和Autoconf都使用特性测试，它们产生的脚本通常不用修改就能在新的Unix版本上运行。因此，它们更容易使用并且适应性更强，而Autoconf也被广泛的应用。1994年，DavidMacKenzie