当我们尝试./configure从源代码运行某些 Linux 软件之前make，通常会执行一大堆检查其他软件参数的操作，例如下面只是这一长串操作中的一小部分：
-- Java Home guessed: /usr/lib/jvm/java
-- Found ANT: /usr/bin/ant
-- Building libhdfs
-- Could NOT find MPI (missing: MPI_LIBRARY MPI_INCLUDE_PATH)
-- MPI Not Found! Distributed Executables will not be compiled
-- Looking for pthread_setaffinity_np
-- Looking for pthread_setaffinity_np - found
-- Performing Test HAS_MARCH_NATIVE
-- Performing Test HAS_MARCH_NATIVE - Success
-- Performing Test HAS_MTUNE_NATIVE
-- Performing Test HAS_MTUNE_NATIVE - Success
-- Performing Test HAS_CRC32
-- Performing Test HAS_CRC32 - Failed
我一直对这一大堆检查感到惊讶——它们真的都是必要的吗？在许多情况下，某些条件失败了——比如示例的最后一行——但是配置继续成功，所以这意味着它们不是必要的？
答案1
有些测试是历史性的。在某些情况下，软件包确实很旧，存在的时间很长，以至于他们试图在旧系统上构建，而这些旧系统没有我们现在拥有的所有资源。但你最好保留这些旧的检查——这不会在大小方面花费太多。
有些检查针对的是多种做事方式。如果你可以用 A 或 B 做某事，那么你可以检查其中任何一种。对 A 的检查可能会失败，但对 B 的检查可能会成功，这样你就可以同样使用 B。
有些检查是针对可选的。如果有一个功能 X 不是必需的，但“有它很酷”，那么您可以检查 X，并在可能的情况下在构建中包含该功能，但将其保留下来并拥有一个可用的包（没有 X）。
那么某些功能确实是必要的，并且任何失败都将中止包构建。
所以，这真的取决于功能；是否有其他选择，我们是否真的需要它，或者这只是“好东西”。
另一件需要考虑的事情是配置几乎已经运行一次，在构建时。任何额外的配置步骤都只是一次，并且不会以任何方式影响运行时。您可以在配置时多等 5 分钟，但仅此而已。这通常不是额外的步骤/尝试进行更稳定的构建的坏权衡。
答案2
它们真的是必要的吗？
这取决于每个程序，但通常大多数都是不需要的。
真正的想法是检查首选程序，如果不可用，则返回到备选程序。例如，检查 ncurses，如果存在：使用。如果不存在，则检查常规 curses 库。如果存在，则使用它，如果不存在，则检查下一个备选程序或中止。
这个想法很棒，但实现起来通常存在缺陷。太多人从其他程序复制 autoconf 和/或 configure 脚本，然后添加东西直到一切正常。这包括很多杂乱无章的东西。