[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Odd warning
Re: Odd warning
Wed, 14 Jan 2004 20:13:38 +0100
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)
>>> "Ralf" == Ralf Corsepius <address@hidden> writes:
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
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
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.
* 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
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)
automake --add-missing --force-missing
or more conveniently:
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.
- Odd warning, Ralf Corsepius, 2004/01/14
- Re: Odd warning,
Alexandre Duret-Lutz <=