Re: Broken makefile given Autoconf version mismatch

[Alexandre Duret-Lutz]

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