./configure 时浪费了大量的时间；特别是当依赖项缺失及其后续调用时。
我读过很多关于这个主题的主题，引用了缓存配置脚本的结果以供重复使用其他配置脚本很容易出错，因为结果过时，事情不同步，并且创建一个共享结果的通用实现将是“很难”[1]。
我想指出的是，我知道配置脚本已经支持缓存，但这是默认禁用 [2]。
如果发行版已经提供了了解相互依赖性的包管理器，并且它们本身已经知道所有常见（甚至最常见）源依赖项是什么，那么为什么发行版没有提供某种配置缓存的标准？人们也许可以假设在给定的某些条件下，包管理器可以评估这些测试中的许多测试根本不需要运行。或者至少，除非配置过程中出现故障，否则不会。
尽管存在许多其他竞争构建系统，但我发现配置仍然是迄今为止最流行的。这些脚本是基于 shell 的、单线程的、容易出错的、通常提供神秘的或不提供诊断信息，并且通常非常慢。对于我来说，由于缺少依赖项（甚至不是配置的一部分）而导致配置脚本或编译失败的情况并不罕见。
有发行版解决过这个问题吗？例如，Gentoo 进行了大量的本地编译。他们会优化这些吗？
我不是在寻找构建系统的建议，而是从历史或文化的角度来了解为什么现代项目仍然严重依赖 autoconf 和配置。这很可能属于意见范围，但我认为这是一个非常有趣的话题，其中可能有基于构建惯例、公司政策和灰胡子习俗的公平事实。
类似的论点可以用邮件列表来提出，与网络上的现代形式协作相比，邮件列表是过时的，但它们也很简单，并且执行的功能与它们一直以来所做的完全相同，鉴于其简单性，几乎没有任何变化。也许 autoconf 也有类似的命运？ （免责声明：我实际上很喜欢邮件列表，任何挫败感都是由于邮件客户端方面的支持不力造成的）。
答案1
在我看来，任何答案都至少是一点点猜测，因为“创新”的构成因人而异（以及这是否是一件好事！）因为它的autoconf设计在很大程度上与语言和架构无关，所以有一个大量的惯性使改变的欲望保持在较低水平：你必须考虑到一些配置脚本可能已经有几十年的历史了，人们不想重写有效的东西。
面临的一些限制autoconf是架构性的：例如，如何在检查多线程的步骤中使用多线程？ 2.5 版是否可以libfoo与声称需要 1.8 版的程序一起使用？您引用的其他问题通常是由于依赖项规格不足造成的：我有许多配置脚本只是忘记列出其所有直接依赖项。最后，autoconf维护者的数量似乎相当有限，因此很难做出巨大的改变。
在某些方面，包管理器是创新发生的地方。它们可以处理诸如需要同一库的不同版本的不同包之类的概念，识别不再可用的依赖项的解决方法，并且（对于像 Gentoo 这样的源代码编译发行版）提供补丁来清理配置脚本和源代码，以便它们正常工作。
答案2
Autoconf 当然会缓存结果，如果你正确使用它，你很少会运行configure.
我的 schilytools 项目（> 4000 个源文件，大约 770000 行代码）目前需要大约。 800 个 autoconf 测试。运行所有测试在 2.7 GHz Intel 笔记本电脑上需要 28 秒，在 1995 年的 HP-9000 披萨盒上需要 2-3 小时，在 1996 年的 Sun3/60 上需要 4-6 小时，而在 1996 年的 Sun3/60 上则需要大约 4-6 小时。 Vax 11/780 上的一天。
我仍然不必担心，因为配置脚本仅更改了大约。每年 5 次，configure在英特尔笔记本电脑上重新运行只需 4 秒，因为所有其他测试都已缓存。当然，我有一个make规则，configure只有在配置结果过期时才会再次运行。
下游民众却有不同的看法。他们将该项目视为一次性数据包，每年全面运行configure30 次，每年需要 15 分钟。
我在另一边一年只需要等待25秒......
那么问题就在于下游人如何使用该软件。