kc3-lang/automake

2023-12-10T09:50:51

automake: again revise file mtime resolution support. This patch is from https://bugs.gnu.org/67670. In order for the Automake testsuite to be able to use sub-second delays to control whether certain files are considered newer than others, five(!) separate pieces of software all need to cooperate: automake itself, autoconf's internal `autom4te' utility, the Perl interpreter and its libraries, the sleep(1) shell utility, and finally the filesystem hosting the build directory. The existing tests for this are a combination of inadequate and incorrect. This patch, in conjunction with a patch just committed to Autoconf trunk, https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=39d96e6fff7ceae63b823872602caf4d255a38c8 should make everything much more robust, as follows: - _AM_FILESYSTEM_TIMESTAMP_RESOLUTION is completely rewritten. It no longer looks for autom4te at all, because this macro is invoked unconditionally from AM_INIT, so *every* project that uses Automake would get this test that's only relevant to Automake's own testsuite. Also, it tries sleeping for as little as one millisecond (smaller delays consistently get rounded up to 1ms on my computer and I expect that's universal), it should accurately detect FAT's two-second resolution now, and it should not be tripped up anymore by running at precisely the moment that will make a 0.1s sleep cross a 1s boundary (this may sound unlikely but it used to cause a couple of test failures *every time* I ran the automake testsuite on a network filesystem that only supported 1s resolution). - In support of the above, the test for working ls -t moved from AM_SANITY_CHECK to _AM_FILESYSTEM_TIMESTAMP_RESOLUTION. This allowed me to simplify the test for $srcdir/configure being older than a freshly created file. - If automake is capable of reading high-resolution file modification timestamps from the operating system, it prints `Features: subsecond-mtime' as the second line of --version output. (We can't just assume this works for sufficiently new automake, because it depends on whether the Perl interpreter provides this capability, and that's not a simple question of which version of Perl you have, either.) - The Autoconf patch mentioned above adds the same annotation to the output of autom4te --version. - Finally, t/ax/test-defs.in looks for the `Features: subsecond-mtime' string from both automake and autom4te and resets the sleep time to one second if it's not there. There might be a better place to put this, somewhere it'll execute every time the *overall testsuite* is invoked rather than once for each test, but I couldn't find one. Tested on x86-64-linux with development automake and development autoconf. Previous discussion: - https://lists.gnu.org/archive/html/automake/2023-03/msg00000.html - https://lists.gnu.org/archive/html/automake/2023-04/msg00002.html - https://lists.gnu.org/archive/html/automake/2023-12/msg00005.html - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64756 * m4/sanity.m4 (_AM_FILESYSTEM_TIMESTAMP_RESOLUTION): Rewrite for greater reliability. Don't probe autom4te at all here. Check for working ls -t here. (AM_SANITY_CHECK): Do not cache the result. Do not check for working `ls -t' here. Disentangle control flow in the loop probing the relative ages of build and source directory. * lib/Automake/FileUtils.pm: Sync from autoconf. * bin/automake.in (version): Include `Features: subsecond-mtime' in the output if $Automake::FileUtils::subsecond_mtime is true. * configure.ac: Rename the substitution variable MODIFICATION_DELAY to MTIME_RESOLUTION. * t/ax/test-defs.in: Require both $AUTOMAKE and $AUTOM4TE to report support for high-resolution timestamps before setting $sleep to delay for less than one second. * NEWS: Update info.