Karl Berry wrote:
jb> The test also guesses the location of autoconf's Perl libraries;
I'm skeptical that any "guessing" of library locations would be reliable
enough.
The guess was the two most probable locations: /usr/share/autoconf and
/usr/local/share/autoconf.
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 version matches a patten that was introduced in commit
c737451f8c17afdb477ad0fe72f534ea837e001e on 2001-09-13 preceding
autoconf-2.52f, and Automake currently requires autoconf-2.65 or later,
so this should work.
Getting the single quotes away from the value without directly
mentioning them is the purpose of the "s/^.//;s/.$//;" part of the sed
command. Wrapping it as "$(eval echo $(sed ...))" would have been
another option to have the shell strip the single quotes.
Automake and autoconf are not two independent tools. Automake completely
relies on autoconf.
It's not for me to hand down any final pronouncements, but personally I
feel strongly that the tests should not paper over this problem by
changing the way tests work in general. With rm -rf of the cache, or
autoconf -f, etc. That is not what users do, so that's not what the
tests should do, either. Such global changes could have all kinds of
other unknown/undesirable effects on the tests.
In contrast to setting the sleep value "as appropriate", which is what
is/should be already done, so changing the conditions under which it is
set is unlikely to cause any unforeseen additional problems.
While potentially compromising the real-world validity of the testsuite
is a legitimate concern, the fact that Automake depends on Autoconf does
not preclude the Automake testsuite from working around Autoconf
limitations in order to accurately test /Automake/.
-- Jacob
