autoreconf can leave config.h.in older than aclocal.m4

[Christian Weisgerber]

Affects at least autoconf 2.69.

While building some projects that use the GNU build system, I ran into
this problem:

Step 1: Run autoreconf to regenerate the files in the GNU build system.
Step 2: ./configure && make

The first build action taken would be an attempt to regenerate
config.h.in with autoheader.  Why?  Because after the autoreconf
run, config.h.in would _sometimes_ be older than aclocal.m4.

The problem is in Autom4te::FileUtils::update_file.  This calls
File::Copy::move to move the newly generated config.h.in file from
a temporary location to the proper destination.  If those are on
different filesystems, rename() will fail and the file is copied.
At the end of the copy the timestamps are set with utime().
Unfortunately utime() only supports full second resolution.  On a
modern POSIX filesystem with nanosecond resolution, config.h.in's
timestamp will be truncated to the nearest second, which can be
older than the just previously generated aclocal.m4 file.

On the one hand, this is a File::Copy bug/limitation.  On the other
hand, maybe Autom4te::FileUtils shouldn't use File::Copy or try to
generate config.h.in under a temporary name in the target directory
so only a rename() will be required.

-- 
Christian "naddy" Weisgerber                          address@hidden