为了在具有许多 CPU 核心（例如 12 个）的工作站上编译软件包，配置阶段通常比实际编译阶段花费的时间更长，因为./configure要逐个进行测试，同时并行make -j运行其他命令。gcc
我觉得让剩下的 11 个核心大部分时间都处于闲置状态，等待缓慢的./configure完成，这是一种巨大的资源浪费。为什么需要按顺序进行测试？每个测试是否相互依赖？我可能错了，但看起来它们中的大多数都是独立的。
更重要的是，有没有什么方法可以加快速度./configure？
编辑：为了说明情况，这里有一个例子GNU 核心实用程序
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比 花费的时间长 6 倍make。虽然./configure使用的 CPU 时间较少（查看“用户”和“系统”时间），但由于未并行化，因此花费的时间（“实际”）要长得多。我重复了几次测试（相关文件可能保留在内存缓存中），时间在 10% 以内。
答案1
我记得大约 10 年前 Autoconf 邮件列表上就讨论过这个问题，当时大多数人实际上只有一个 CPU 核心。但什么也没做，我怀疑也不会做。在 中设置并行处理的所有依赖项configure并以可移植且健壮的方式进行设置将非常困难。
根据您的具体情况，可能有几种方法可以加快配置运行速度。例如：
- 使用更快的 shell。例如，考虑使用
dash而不是bashas/bin/sh。（注意：在 Debian 下，dash已修补，因此configure不会使用它，因为使用它会破坏很多configure脚本。） - 如果您远程运行构建（例如通过 ssh），那么我发现控制台输出可能非常慢。考虑调用
configure -q。 - 如果重复构建同一个项目，请考虑使用缓存文件。调用
configure -C。有关详细信息，请参阅 Autoconf 文档。 - 如果您构建了许多不同的项目，请考虑使用站点文件 (
config.site)。再次参阅文档。 - 并行构建多个项目。
答案2
您很聪明地使用 ramdrive 来存放 sourcetree，但请再想一想 - configure 是做什么的？它的工作不仅仅是检查您的源树，但往往也是系统用于库、编译器等的可用性。在这种情况下，访问问题有时存在于磁盘访问中 - 如果您拥有例如基于 SSD 的根文件系统，则可以更快地完成它。
答案3
脚本有很多种类型./configure。有流行的工具（自动配置开发人员可以使用许多工具（例如，Java 和 PHP）来帮助开发人员创建./configure脚本，但是并没有规定说每个开发人员都必须使用这些工具，而且即使在这些工具中，这些脚本的构建方式也会有很大差异。
我不知道有哪些流行的./configure脚本可以并行运行。大多数由流行工具构建的脚本至少会缓存部分或全部结果，因此如果您再次运行它（make clean无论如何无需执行第一次），第二次运行速度会快得多。
这并不是说做不到……但我怀疑，从事相关工作的人们没有什么动力autoconf去做这件事，因为最多包，配置阶段相对于实际的编译和链接阶段非常快。
答案4
如果您使用的是按需 CPU 调节器，请尝试使用性能调节器。这对 i7 和 a8-3850 的帮助为 40-50%。对 q9300 的影响不大。
在四核 CPU 上，你可以这样做
for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done
（-r 选项应该使您不必为每个核心执行 cpufreq-set，但在我的计算机上它不起作用。）
但是，缓存选项还有更多帮助。