Timestamps, GNU autotools, and repositories

If you include the distributed source for software that uses the GNU autotools in a source repository, beware of timestamps on the files when you checkout the source.

Consider, for example, the source distribution of the GNU MPFR library. The source distribution includes the files aclocal.m4 and Makefile.in. In the autotools world, Makefile.in is dependent on aclocal.m4. When you run configure, the Makefile is derived from Makefile.in.

This all fine and not surprising. What will be surprising is that when you run make, you may immediately get an error like this.

> gmake
/home/woz/tmp/testing/mpfr/missing: automake-1.15: not found
WARNING: 'automake-1.15' is missing on your system.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
gmake: *** [Makefile:404: ../mpfr/Makefile.in] Error 1

The distribution may create a Makefile whose first course of action is to check that the build files are up-to-date. This means checking files such as aclocal.m4 and Makefile.in. If the timestamps on those files are such that Makefile.in is ever-so-slightly older than aclocal.m4, for example, the build will attempt to regenerate Makefile.in, which requires automake to be installed. It may even complain about having a specific version, such as in the example above. Perhaps more insidiously, if you do have the correct version installed, it will regenerate the file in the source directory. You may be really confused to see a modified Makefile.in (or .info files, or perhaps machine descriptions) after doing a clean checkout and build. (It’s also bad because, technically, the build is based on different source than what is in the repository.)

I’ve run into this where the distributed source for libraries such as MPFR are included in large source repositories. When cloning them, you never know what order the files will be written and when. If you try to do this with a small repository, there’s a very good chance the timestamps of the files will be the same.

This likely won’t happen when the source is unpacked from the distribution because TAR files preserve the timestamps.

If there’s an option to configure to prevent this, such as --disable-maintainer-mode, you may want to use that. (Why would “maintainer mode” be the default in the first place?) You could also touch the troublesome files in the correct order, although that will probably bring about its own maintenance headaches.