Mike Frysinger wrote:
On 02 Dec 2023 17:07, Jacob Bachmeyer wrote:
Mike Frysinger wrote:
On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
Karl Berry wrote:
jb> a more thorough test would locate the autom4te script and grep it
for the perllibdir that was substituted when autoconf was
configured.
I guess that would work.
Challenge accepted. Here's a refined version: (lines \-folded for email)
if $PERL -I${autom4te_perllibdir:-$(sed -n \
'/autom4te_perllibdir/{s/^.*|| //;s/;$//;s/^.//;s/.$//;p;q}' \
<$(command -v autom4te))} -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 doesn't work on systems that wrap `autom4te`. [...]
[...]
so i don't know why we would need to set/export autom4te_perllibdir in our
wrapper. we've been doing this for over 20 years without ever setting that
var (or any other internal autoconf/automake var), so i'm pretty confident
our approach is OK.
No, not in the wrapper---in the automake ebuild script that runs
configure to match the autom4te that the wrapper will run. That test I
proposed checks for autom4te_perllibdir in the environment before
extracting it from autom4te precisely so distributions like Gentoo would
have a knob to turn if their packaging breaks that test.
That said, it turns out that this whole line of discussion is now a red
herring; see below.
[...]
i'm not aware of anything loading the Autom4te perl modules outside of the
autoconf projects. does that actually happen ? i don't think we want to
have automake start loading autoconf perl modules directly. going through
the CLI interface seems better at this point.
Autoconf and Automake are very closely associated; there is even some
shared code that is synchronized between them. Autom4te::FileUtils is
also Automake::FileUtils, for example.
The test we are discussing here was intended for Automake's configure
script to use to check if the installed Autoconf has high-resolution
timestamp support. It turned out that the test I wrote can give a false
positive, as some versions of other dependencies of Autom4te::FileUtils
/also/ use Time::HiRes, causing the test to correctly report that
Time::HiRes was loaded, but Autom4te::FileUtils nonetheless does not
actually use it. The test could probably be improved to fix the false
positives, but that would be getting into deep magic in Perl that might
not be fully reliable across Perl versions. (It would be necessary to
determine if (a) Time::HiRes::stat exists and (b)
Autom4te::FileUtils::stat is an alias to it. Having configure build a
special XSUB just to check this is well into "ridiculous" territory.)
As such, the Automake maintainers replaced this particular test with a
simpler test that just locates Autom4te/FileUtils.pm and greps it for
"Time::HiRes", thus the error message you received, which initially had
me confused because the test I proposed cannot produce that message as
it does not use grep.
An important bit of context to keep in mind is that I am not certain
that timestamp resolution is still a problem outside of the Automake and
Autoconf testsuites, since Autoconf and Automake now require cache files
to actually be newer than their sources and consider the cache files
stale if the timestamps are equal. This is a problem for the testsuite
because the testsuite is supposed to actually exercise the caching
mechanism, and higher-resolution timestamps can significantly reduce the
amount of time required to run the tests by reducing the delays needed
to ensure the caches will be valid.
-- Jacob
