Karl Berry <k...@freefriends.org>, Mon Apr 03 2023 02:08:23 GMT+0200
(Central European Summer Time)
I modified my autom4te using the attached patch,
Thank you very very much for finding this, Bogdan.
:) Hope it saved some headaches :)
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.
Perhaps. If not possible to call the autom4te's routine/module
directly, it could be possible to make a loop similar to the one
already in place (the filesystem timestamp resolution). But this loop
would require calling autom4te the number of times needed to establish
the result, which could make just this testing longer than the gain...
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.
Until autoconf/autom4te has a '--has=some-feature-name' option,
checking the version number would probably be the best, as you say.
Best, not easy :). Compare '2.71' to '2.72-beta1-snapshot-12345678' or
vice versa with the suffixes :). Some nice Perl one-liner should do
the trick.
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.
I agree, so it would be best to have a workaround or a plan "B" for
those unpatched, for some reasonable time, at least. What would the
plan be is the question. Force '-f'? Run an initial pre-test for
autom4te and generate the $AUTOCONF variable? Run an initial pre-test
for autom4te and force the timeout in the tests (like set an
environment variable, check for that in the sanity test and assume 1
second sleep if present)?
But, fortunately, these are still "just tests".
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.
On one hand - yes, you're right. On the other - we're working around
an issue with SOME OTHER TOOL. Just like #ifdef/#endif with C
compilers, Perl's 'eval' at runtime, or whatever.
I think we're allowed to do whatever workaround we find suitable to
make Automake work or make its tests pass. Obviously, it would be best
if autoconf/autom4te we patched (preferably from the beginning), but
if we can't have everything else perfect, we do our best, including
the old 'sleep 1' in the sanity test (and probably other things).
Bogdan
P.S. Sorry for not replying earlier. I wanted to come back with some
results, but apparently, it will take a bit more time.
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux): http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
