automake version (am__api_version) hardcoded in configure script

7
votes

I'm currently working on a Linux project using autotools. The code is submitted in SCM (Perforce) and we have the configure script, Makefile.am, Makefile.in - the usual autotools boilerplate. Recently, somebody has changed Makefile.am, but forgot to regenerate Makefile.in; when I tried to build, I got this error:

WARNING: `automake-1.11' is missing on your system.  You should only need it if
         you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
         You might want to install the `Automake' and `Perl' packages.
         Grab them from any GNU archive site.
 cd . && /bin/bash ./config.status Makefile depfiles

I see the automake version is hardcoded in the configure script (and seems to come from aclocal.m4): 

am__api_version='1.11'

So I guess I need automake-1.11 (not 1.10, not anything newer) to regenerate the Makefile.in file.

Why is that? Why should we be tied to a specific automake version? We're mostly building on Ubuntu 14.04, where 1.14 is the default version installed. Is there a way to tell the build system to simply use whatever version of automake is installed? Or is it safe to maybe remove the am__api_version definition from aclocal.m4?

2
linuxmakefileautotoolsautomake
I would define "the usual autotools boilerplate" to be configure.ac and Makefile.am. It is the purpose of these two files is to generate the configure script, the Makefile.in, the Makefile, and various other artifacts that support the build. Generated files need not (indeed, should not) be added to any source control. - rubicks

2 Answers

2
votes

The problem is that you are trying to recreate Makefile.in with other version of autotools. It would lead to version mismatch as aclocal.m4 was built with different version and it is used to generate the remaining files.

Instead of recreating only Makefile.in, try to also recreate aclocal.m4 and all remaining autotools generated files:

autoreconf --force --install
1
votes

The important question is why would someone fix am__api_versions. The most probable answer is: Because automake tends to alter the macro's arguments or even remove entirely macros of previous release. In each release announcement of automake there is a section called

WARNING: Future backward-incompatibilities!

and an other one called

Obsolete features removed

You can refer to releases 1.12, 1.13, 1.14

So the configure.ac or Makefile.am might contain some macros which have become obsolete in later releases. When encountering this problem you have two possibilities. Either find out which feature replaced the obsolete one or stick to one version of automake. Most developers do not feel that autotools files are part of the projects source code. They just wish to keep the working version running and stick to the current am version.

Note that all distributions support older versions of automake. In ubuntu you can find:

$ apt-cache search automake | grep automake
automake - Tool for generating GNU Standards-compliant Makefiles
automake1.4 - A tool for generating GNU Standards-compliant Makefiles
automake1.9 - A tool for generating GNU Standards-compliant Makefiles
automake1.10 - Tool for generating GNU Standards-compliant Makefiles
automake1.11 - Tool for generating GNU Standards-compliant Makefiles

Meaning that you can install the requested version of automake.

So, you could remove the line am__api_version='1.11' and find out which macro is obsolete. Then you will have to decide which of the above two solutions you will follow.