7

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?

fencekicker
  • 732
  • 1
  • 8
  • 18
  • 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 Dec 14 '15 at 14:33

2 Answers2

3

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
baf
  • 4,531
  • 1
  • 21
  • 24
  • So I guess the choice is between: - don't store any generated files in Perforce and always run 'autoreconf -fvi' - store aclocal.m4, configure, Makefile.in in Perforce, but then you need the exact automake version that generated them whenever you modify any input file(s)? Of course, there's always option 3 - ditch autotools :). – fencekicker Apr 20 '15 at 13:15
  • Your problem is: "somebody has changed Makefile.am, but forgot to regenerate Makefile.in". Otherwise everything should work as designed :) – baf Apr 20 '15 at 13:19
  • @fencekicker If you store aclocal.m4, configure, Makefile.in generated by the same version of autotools you don't have to care about automake version – baf Apr 20 '15 at 13:23
  • What I ended up doing was to remove all autotools-generated files from Perforce, and added one build step that regenerates them. This seems to be the most sensible approach, at least for us. Then locally you can generate them once and be done with it. The nightly build always regenerates everything, so no more worries about keeping Makefile.in, Makefile.am and what not in sync. – fencekicker May 04 '15 at 16:18
1

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.

ztik
  • 3,482
  • 16
  • 34
  • The snippet where the version is pinned is generated by automake itself - it generates files that can only be partially regenerated (e.g. regenerate Makefile.in but not aclocal.m4 etc) with the same version of itself. At least that's my understanding. I could modify configure, but if it would ever be regenerated it would be overwritten. – fencekicker Apr 21 '15 at 09:42
  • @fencekicker sorry for my misunderstanding. In the question it was implied that the `am` version was fixed by the user. – ztik Apr 21 '15 at 09:47