configure脚本如何决定重新生成自己

KiR*_*iCH 5 autoconf configure

当我运行./configure时,它有时会判断它太旧了,并通过丢失的脚本重新运行autoconf来重新生成自己.有时它会导致奇怪的破坏,因为目标机器上的autoconf比用于最初生成configure的autoconf更旧.

我想知道它是如何计算出它太旧了?有没有一种标准的配置方式呢?或者它取决于图书馆.指向文档的指针将不胜感激.

adl*_*adl 9

configure不会这样做:make是的.如果configure脚本早于configure.ac它包含的任何文件(从头开始aclocal.m4),则make运行autoconf以重建configure.

存在类似的规则来重建aclocal.m4使用aclocal和各种Makefile.in使用automake.

在目标计算机上解压缩tarball之后,永远不应该触发这些重建规则,因为tarball中所有这些文件的时间戳应该是正确的(configure比configure.ac等等更新).所以,如果发生这种情况,你的tarball中的任何东西都是假的(就像你没有使用make dist或最好make distcheck生成它),或者编译源代码的用户做错了(比如复制整个目录而不保留时间戳),或者有目标系统中出现虚假的情况(例如,make如果NFS服务器的时钟与客户端的时钟不同步,则通常无法在NFS安装的目录上正常工作).

在版本控制系统中保存生成的文件的人观察到另一个不受欢迎的重建的常见原因.如果是这种情况,请参阅http://sourceware.org/automake/automake.html#CVS以获取有关此问题的讨论.

  • @KiRPiCH:还要注意,对于现代`automake`,你通常可以通过运行`autoreconf -i`从`configure.ac` +`Makefile.am`到准备好`./configure`.无需担心以正确的顺序运行`aclocal`,`autoconf`,`autoheader`,`automake`,`libtoolize`等等.如果这还不够,那么创建一个名为`bootstrap.sh`的脚本(`autogen.sh`是另一个常用名称,但有一个名为`autogen`的模糊工具)以正确的顺序运行autotools. (4认同)
  • 我会先发制人地补充一点,"AM_MAINTAINER_MODE"不是解决方案.它只是增加了另一个可能发生破损的点.不要将生成的文件保存在源代码管理中,并使用`make distcheck`来构建tarball,你应该没问题. (3认同)