Re: rhel8 test failure confirmation?
Karl Berry wrote:
[...]
What can we do about this?
As for automake: can we (you :) somehow modify the computation of the
sleep value to determine if autom4te can handle the HiRes testing or not
(i.e., has the patch installed)? And then use the longer sleep in
automake testing if needed.
If you can locate Autom4te::FileUtils, grepping it for "Time::HiRes"
will tell you if autom4te supports sub-second timestamps, but then you
need more checks to validate that the filesystem actually has sub-second
timestamps.
A simple check:
if $PERL -I${autom4te_perllibdir:-/usr/share/autoconf}
-I/usr/local/share/autoconf \
-MAutom4te::FileUtils -e 'exit defined $INC{q[Time/HiRes.pm]} ?
0 : 1'; then
# autom4te uses Time::HiRes
else
# autom4te does not use Time::HiRes
fi
This method also has the advantage of implicitly also checking that
$PERL has Time::HiRes installed by determining if loading
Autom4te::FileUtils causes Time::HiRes to be loaded. (In other words,
this will give the correct answer on Perl 5.6 if Time::HiRes was
installed from CPAN or on later Perls if a distribution packager has
unbundled Time::HiRes and the user has not installed its package.)
[...]
It seems to me that using autoconf -f or similar is papering over the
problem, so that the tests are no longer testing the normal behavior.
Which does not sound desirable.
The Automake testsuite is supposed to test Automake, not Autoconf, so
working around Autoconf issues is appropriate. In this case, if always
using "autoconf -f" allows us to eliminate the sleeps entirely (and does
not expand the running time of Autoconf too much), we should do that, at
least in my view.
-- Jacob
faster tests [was: rhel8 test failure confirmation?]
# A trick to make the test run muuuch faster, by avoiding repeated # runs of aclocal (one order of magnitude improvement in speed!). echo 'AC_INIT(x,0) AM_INIT_AUTOMAKE' > configure.ac Hadn't noticed this before. Maybe you could see what tests are currently taking the longest to run, and see if the above helps speed them up? It seems a somewhat weird thing to do, but if it saves enough time, I guess it would be worth it. --thanks, karl.
Re: rhel8 test failure confirmation?
I modified my autom4te using the attached patch, Thank you very very much for finding this, Bogdan. I'm glad that Paul has already installed it in Autoconf. I can't easily confirm it for myself right now, but I'm hopeful. (Maybe Frederic or others can try with the development autoconf.) What can we do about this? As for automake: can we (you :) somehow modify the computation of the sleep value to determine if autom4te can handle the HiRes testing or not (i.e., has the patch installed)? And then use the longer sleep in automake testing if needed. In fact, I wonder about autom4te providing an explicit way to test whether it's been patched, because I suspect that a functionality test (run autom4te a bunch of times on a bunch of newly-created files) would be highly susceptible to wrong results. Checking the autom4te --version number might be the easiest and best thing to do. I think it's pretty crucial that the automake (or autoconf) tests not spuriously fail due to filesystem timing, even for people that have the "old" (unpatched) autom4te. People will certainly keep using current and older releases of autoconf for years to come. It seems to me that using autoconf -f or similar is papering over the problem, so that the tests are no longer testing the normal behavior. Which does not sound desirable. Wdyt? --thanks again, karl.
