是否可以加快 ./configure 的速度？

Question

要在具有许多 CPU 内核（比如 12 个）的工作站上编译软件包，配置阶段通常比实际编译阶段花费的时间长得多，因为./configure测试是一个一个，同时make -j运行gcc以及其他命令并行。

我觉得让剩下的 11 个内核大部分时间都闲置等待慢速./configure完成是一种巨大的资源浪费。为什么需要按顺序进行测试？每个测试是否相互依赖？我可能会弄错，但看起来他们中的大多数都是独立的。

更重要的是，有什么方法可以加快速度./configure吗？

---

编辑：为了说明这种情况，这里有一个GNU Coreutils的例子

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

结果：

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

使用coreutils-8.9，./configure比make. 尽管./configure使用较少的 CPU 时间（查看“用户”和“系统”时间），但它需要更长的时间（“真实”），因为它不是并行化的。我已经重复了几次测试（相关文件可能留在内存缓存中），次数都在 10% 以内。

Answer 1

我记得大约 10 年前 Autoconf 邮件列表上关于这个问题的讨论，当时大多数人实际上只有一个 CPU 内核。但是什么都没有做，我怀疑什么也不会做。在 中为并行处理设置所有依赖项configure，并以可移植和健壮的方式进行设置将非常困难。

根据您的特定场景，可能有几种方法可以加速配置运行。例如：

• 使用更快的外壳。例如，考虑使用dash而不是bashas /bin/sh。（注意：在 Debian 下，dash打了补丁所以configure不使用它，因为使用它会破坏很多configure脚本。）
• 如果您远程运行构建（例如通过 ssh），那么我发现控制台输出可能非常慢。考虑调用configure -q.
• 如果重复构建同一个项目，请考虑使用缓存文件。打电话configure -C。有关详细信息，请参阅 Autoconf 文档。
• 如果您构建许多不同的项目，请考虑使用站点文件 ( config.site)。再次，请参阅文档。
• 并行构建多个项目。

Answer 2

脚本有很多种类型./configure。有一些流行的工具（autconf是其中之一）可以帮助开发人员创建./configure脚本，但没有规则说每个开发人员都必须使用这些工具，而且即使在这些工具中，这些脚本的方式也可能存在很大差异被建造。

我不知道有任何./configure可以并行运行的流行脚本。大多数由流行工具构建的脚本至少会缓存部分或全部结果，因此，如果您再次运行它（无论如何make clean，无需执行第一次），它第二次运行得更快。

这并不是说它无法完成......但我怀疑从事这项工作的人们没有什么动力autoconf去做这件事，因为对于大多数包来说，配置阶段相对于实际的编译和链接来说非常快阶段。