Re: automatic update Makefile.am -> Makefile.in -> Makefile no longer working

[Ralf Wildenhues]

Hello world,

* Eric Blake wrote on Thu, Jun 21, 2007 at 02:16:32PM CEST:
> According to Paul Eggert on 6/20/2007 11:36 PM:
> > 
> > +[m4_warning([this file was generated for autoconf $ac_version.
> > +You have another version of autoconf.  It may work, but it may not.
> > +If you have problems, you may need to regenerate the build system 
> > entirely.])])

Thanks for the bug report, discussion, and patch.

> ...except should we also mention 'autoreconf' as the way to regenerate
> the build system?

autoreconf may not always be appropriate.  Also, to my humble non-native
English ear, the sentence `It may work, but it may not.' sounds strange.
How about this?

[m4_warning([this file was generated for autoconf $ac_version.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 
`autoreconf'.])])

And tests/missing4.test needs to be fixed appropriately (see
  cd tests && make check VERBOSE=yes TESTS=missing4.test
).

And NEWS should have (since it mentioned the check introduction in 1.10)
something like:

  - The autoconf version check implemented by aclocal in aclocal.m4
    is degraded to a warning.

I think this should be applied to HEAD and branch-1-10.
Would you like me to do it?

With this patch, of course maintenance of Automake gets yet another bit
harder: if the user had overlooked this warning at one point in time,
and it just so happened that the version difference was an incompatible
one, then it is even more difficult to reconstruct this after the fact.
Of course the problem existed rather similarly before this patch, only
that a Makefile.in that was not updated at all due to the version
difference is usually much easier to detect as inconsistent with
Makefile.am.

So this is yet another reason to keep Autoconf version incompatibilities
as few as possible.  Which is in turn a reason for Autoconf to have a
testsuite with as extensive coverage of functionality as possible.  ;-)

Cheers,
Ralf