Noah: | `automake' can generate a Makefile.in that does not fit | `configure' if the version of Autoconf it uses to trace | `configure.ac' differs from the version used to generate | `configure'. The Autoconf version used by Automake should also be the same used by aclocal. Maybe aclocal could output some code in aclocal.m4 to ensure that the autoconf version that reads aclocal.m4 is the same as the version that was traced to generate it. The consequences of such a test are not entirely clear to me, but it looks like it would prevent the version mismatch we are discussing: - If you have another autoconf installed and try to update a Makefile.am, the rebuild rule will call automake which will will call autoconf which will barf on aclocal.m4 and exit with $?=63, causing missing to take over. - Likewise if you try to simply regenerate configure with a different autoconf version. - If you update a dependence of aclocal.m4 (e.g., configure.ac, or M4 macros), all the build system will be regenerated with your tools. On the implementation side, I guess the M4 fragment added by aclocal.m4 would have to compare the value of m4_PACKAGE_VERSION with the value traced (if that's possible) when aclocal was run. (AC_PREREQ would only prevent downgrading autoconf without rerunning automake, while we are discussing about upgrading it too.) In case this check doesn't sound appropriate for non-automake-based package, we could also arrange that it be only performed inside AM_INIT_AUTOMAKE. -- Alexandre Duret-Lutz Shared books are happy books. http://www.bookcrossing.com/friend/gadl _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
