关于Autoconf的问题

有时我们会遇到几个关于Autoconf的问题。下面是被提及的一些问题。

发布configure脚本

对发行由Autoconf生成的configure有什么限制?它们是如何影响我那些使用它们的程序的?

关于由Autoconf生成的配置脚本是如何发行和如何被使用的，并没有限制。在Autoconf第1版中，它们是服从GNU通用公共许可证的。 我们仍然鼓励软件的作者按照诸如GPL的条款发行他们的作品，但Autoconf并不要求这样做。

关于可能由configure使用的其它文件，'config.h.in'服从你为你的'configure.in'而使用的 任何版权规定，这是因为它是从那个文件和公有文件'acconfig.h'中派生出来的。当'config.sub'和 'config.guess'被用于由Autoconf生成的、允许你按照与你的软件包其它部分相同的条款发布的configure 脚本中时，它们就是GPL的一个例外。'install-sh'是来自于X Consortium并且是没有版权

的。

为什么需要使用GNU m4?

为什么Autoconf需要使用GNU m4?

许多m4的实现含有编码性(hard—coded)的，对宏的大小和数鼠的限制，Autoconf超过了这些限制。 它们还缺少一些内置宏，没有它们，诸如Autoconf之类的复杂应用程序将难以应付，它们包括：

因为只有软件维护者需要使用Autoconf，并且因为GNU m4易于配置和安装，需要安装GNU m4 好像是合理的。许多GNU和其它自由软件的维护者，因为他们更喜爱GNU工具，都已经安装了大部分GNU工具。

我如何解开死结?

如果Autoconf需要GNU m4并且GNU m4还有一个Autoconf configure脚本，我如何解开这个死结?它好像是一个类似于鸡和蛋的问题，

这实际上是一种误解。虽然GNU m4带有一个由Autoconf生成的configure脚本，但在运行脚本 及安装GNU m4的时候并不需要安装Autoconf。只有在你需要修改m4的configure 脚本的时候，这只是少数几个入(主要是它的维护者)必须去作的事，才需 要Autoconf。

为什么不使用Imake?

为什么不用Imake来代替configure脚本?

有些入已经提出了这个问题，所以在改编之后，我把给他们的解释写在这里。下面是对Richard Pixley的问题的回答：

由Autoconf生成的脚本经常地在它以前从未设置过的机器上工作。这就是说，它善于推断新系统的配置。而Imake不能做到。

Imake使用含有主机特定数据的通用数据库。对X11来说，这种方法具有意义是因为发布版本是由一个控制整个 数据库的总管机关管理的一组工具组成的。

GNU工具并不按这种方式发行。每个GNU工具都有一个维护者 这些维护者散布在世界各地。使用统一的数据库将使维护变成噩梦。

Autoconf可能成为这类数据库，但实际上它没有。不是列举主机的依赖性，它列举的是程序的需求。

如果你把GNU套件看作一组本地工具，那么问题就很相似了。但GNU开发工具可以作为交叉工具(cross tools)而在几乎 所有主机+目标机的组合中进行配置。所有的这些配置都可以同时(concurrency)安装。它们甚至可以被配置成可以在不同主机上共享 与主机独立的信息的形式。Imake不能处理这些问题。

Imake模板是标准的一种形式。GNU编码标准在没有强加相同的限制的情况下，解决了相同的问题。下面是一些由Per Bothner撰写的进一步的解释：

Imake的一个长处是它易于通过使用cpp的'#include'和宏机制生成大的Makefile。 然而，cpp是不可编程的：它含有有限的条件工具，而不含有循环。而且cpp不能检查它的环境。

所有这些问题可以通过使用sh而不是cpp来解决。shell是完全可编程的、含有宏替换、可以执行 (或者编制)其它的shell脚本，并且可以检查它的环境。

Paul Eggert更详细地阐述：

使用Autoconf，安装者不必假定Imake自身已经被安装并且正常地工作了。这对于习惯使用Imake的入们来说，看起来不是 突出的长处。但在许多主机上，并没有安装Imake或者缺省的安装不能很好地工作，为此，要求安装Imake就阻碍了在这些主机 上使用由Imake配置的软件包。例如，Imake模板和配置文件可能不能适当地安装在一个主机上，或者Imake创建过程可能 会错误地假定所有的源代码文件都在一个大目录树中，或者Imake配置可能使用某个编译器而包或者安装器需要使用另一个编译器， 或者包需要的Imake的版本号与系统支持的版本号不匹配。这些问题在Autoconf中很少出现，这是因为包附带属于它自己的 独立配置处理器。

还有，Imake通常会在make和安装者的C预处理器之间遇到难以预期的影响。这里的基本问题是，C预处理器 是为处理C程序而不

是'Makefile'而设计的。这对Autoconf来说问题小得多，它使用通用目的预处理器m4， 并且包的作者(而不是安装者)以标准的方式进行预处理。

最后，Mark Eichin解释道：

Imake还不是完全可扩展的。为了把新特征添加到Imake中，你需要提供你自己的项目模板，并且复制已经存在的特征的主要部分。 这意味着对于复杂的项目来说，使用由买主提供的(vendor—provided)Imake模板不能提供任何平衡作用——这是因为它们不包括 你自己的项目的任何东西(除非它是一个X11程序)。

但是，另一方面：

一个Imake胜过configure的长处是： 'Imakefile'总是趋向于比'Makefile.in'简短(同样地，冗余较少)。 但是，这儿有一个修正的方法——至少对于Kerberos V3树来说，我们已经在整个树中进行了修改以调用通用的 'post.in'和'pre.in' 'Makefile'片断。 这意味着大部分通用的东西，即使它们通常是在configure中设置的，也不必复制。