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 na...@mips.inka.de
