为什么不用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 V5树来说，我们已经在整个树中进行了修改以调用通用的 post.in'和pre.in’ `Makefile’片断。 这意味着大部分通用的东西，即使它们通常是在configure中设置的，也不必复制。