Re: Odd warning

[Alexandre Duret-Lutz]

>>> "Ralf" == Ralf Corsepius <address@hidden> writes:

 Ralf> Hi,
 Ralf> After having upgraded from automake-1.8.1 to automake-1.8.2 (And having
 Ralf> modified some Makefile.ams), I received this warning from automake:

 Ralf> configure.ac:16: version mismatch.  This is Automake 1.8.2,
 Ralf> configure.ac:16: but the definition used by this AM_INIT_AUTOMAKE
 Ralf> configure.ac:16: comes from Automake 1.8.1.  You should recreate
 Ralf> configure.ac:16: aclocal.m4 with aclocal and run automake again.
 Ralf> WARNING: `automake-1.8' is probably too old.  You should only need it if
 Ralf> you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
 Ralf> You might want to install the `Automake' and `Perl' packages.
 Ralf> Grab them from any GNU archive site.
 Ralf> cd . && /bin/sh ./config.status Makefile

 Ralf> I don't understand why this warning is issued.

 Ralf> To my understanding automake-1.8.1 and automake-1.8.2 both should
 Ralf> implement the automake-1.8 API and therefore should be sufficiently
 Ralf> compatible.

It's the `Automake API', not the `automake API'.  I.e., the API
applies to the package, not to the individual command.  

For instance generated Makefile rules can rely on internal
configure substitutions defined by M4 macros, and this
interaction is not covered by the API.

How about adding the appended section to the manual?

 Ralf> Therefore, I don't understand why 
 Ralf> 1. this warning is required at all.
 Ralf> 2. automake doesn't automatically try to do what it recommends the user
 Ralf> to do manually: running aclocal and automake.

That makes sense to me, but this looks a bit complicated to
implement, and (I feel) more error prone that the current
situation.  

One problem is that aclocal needs to be passed ACLOCAL_AMFLAGS, which
  1) is not know in all directories
  2) is not available at the time the warning is issued

Another problem is that if automake was called to regenerate one
Makefile.in, and consequently aclocal is run to update
aclocal.m4, then all other Makefile.ins should be regenerated
(the automatic rebuild rules will probably take care of that,
but not every body use them).

====

Upgrading a Package to a Newer Automake Version
***********************************************

Automake maintains three kind of files in a package.

   * `aclocal.m4'

   * `Makefile.in's

   * auxiliary tools like `install-sh' or `py-compile'
   
   `aclocal.m4' is generated by `aclocal' and contains some
Automake-supplied M4 macros.  Auxiliary tools are installed by
`automake --add-missing' when needed.  `Makefile.in's are built from
`Makefile.am' by `automake', and rely on the definitions of the M4
macros put in `aclocal.m4' as well as the behavior of the auxiliary
tools installed.

   Because all these files are closely related, it is important to
regenerate all of them when upgrading to a newer Automake release.  The
usual way to do that is
   
     aclocal # with any option needed (such a -I m4)
     autoconf
     automake --add-missing --force-missing

or more conveniently:

     autoreconf -vfi

   The use of `--force-missing' ensures that auxiliary tools will be
overridden by new versions (*note Invoking Automake::).

   It is important to regenerate all these files each time Automake is
upgraded, even between bug fixes releases.  For instance it is not
unusual for a bug fix to involve changes to both the rules generated in
`Makefile.in' and the supporting M4 macros copied to `aclocal.m4'.

   Presently `automake' is able to diagnose situations where
`aclocal.m4' has been generated with another version of `aclocal'.
However it never checks whether auxiliary scripts are up-to-date.  In
other words, `automake' will tell you when `aclocal' needs to be rerun,
but it will never diagnose a missing `--force-missing'.

   Before upgrading to a new major release, it is a good idea to read
the file `NEWS'.  This file lists all changes between releases: new
features, obsolete constructs, known incompatibilities, and workarounds.

-- 
Alexandre Duret-Lutz