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
Makefile.in. In the autotools world,
Makefile.in is dependent on
aclocal.m4. When you run
Makefile is derived
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
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
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.