【发布时间】：2020-01-03 14:39:08
【问题描述】：
当我运行 ./configure 时，有时它会认为它太旧并通过丢失的脚本重新运行 autoconf 以重新生成自身。有时它会导致奇怪的破损，因为 autoconf on 目标机器比最初用于生成配置的 autoconf 旧。
我想知道它是如何发现它太旧的？有没有标准的配置方法来做到这一点？或者它取决于图书馆。指向文档的指针 受到赞赏。
【问题讨论】：
【发布时间】：2020-01-03 14:39:08
【问题描述】：
configure 不决定这一点：make 决定。如果configure 脚本早于configure.ac 或它包含的任何文件（以aclocal.m4 开头），则make 运行autoconf 以重建configure。
存在使用aclocal 重建aclocal.m4 和使用automake 重建各种Makefile.in 的类似规则。
在目标计算机上解压缩 tarball 后，永远不应触发这些重建规则，因为 tarball 中所有这些文件的时间戳应该是正确的（configure 比 configure.ac 更新，等等）。因此，如果发生这种情况，要么是你的 tarball 中的某些东西是伪造的（比如你没有使用 make dist 或者最好是 make distcheck 来生成它），或者编译源代码的用户做错了（比如复制整个目录而不保留时间戳），或者目标系统中存在虚假内容（例如，如果 NFS-server 的时钟与客户端的时钟不同步，make 通常无法在 NFS-mounted 目录上正常工作）。
将生成的文件保存在版本控制系统中的人观察到另一个常见的不受欢迎的重建来源。如果您遇到这种情况，请参阅 https://www.gnu.org/software/automake/manual/html_node/CVS.html 进行讨论。
【讨论】：
-
我会先发制人地补充说
AM_MAINTAINER_MODE不是解决方案。它只是增加了另一个可能发生破损的点。不要将生成的文件保存在源代码管理中并使用make distcheck来构建tarball，你应该没问题。 -
罪魁祸首最终是 git，因为它不保留时间戳 configure.ac 被检出比配置更新。需要研究为什么我们将生成的文件置于源代码控制之下的问题。
-
@KiRPiCH：还请注意，使用现代
automake，您通常可以通过运行autoreconf -i从configure.ac+Makefile.am转到./configure。无需担心以正确的顺序运行aclocal、autoconf、autoheader、automake、libtoolize和其他任何东西。如果这还不够，请创建一个名为bootstrap.sh的脚本（autogen.sh是另一个常用名称，但有一个名为autogen的不起眼的工具）以正确的顺序运行自动工具。