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`. Gentoo for example wraps
all autoconf & automake scripts to support parallel installs of different
versions. this way we can easily have access to every autoconf version. we
got this idea from Mandrake, so we aren't the only ones ;).
as such, running git configure produces errors:
checking for autom4te... /usr/bin/autom4te
grep: /Autom4te/FileUtils.pm: No such file or directory
checking the filesystem timestamp resolution... 2
and then breaks some tests:
$ grep ^FAIL: test-suite.log
FAIL: t/depcomp2
FAIL: t/distcheck-no-prefix-or-srcdir-override
t/depcomp2.log showing:
+ cat stderr
grep: /Autom4te/FileUtils.pm: No such file or directory
+ sed /rm:.*conftest\.dSYM/d stderr
+ test -s stderr2
+ cat stderr2
grep: /Autom4te/FileUtils.pm: No such file or directory
+ _am_exit 1
seems like the only reliable option is to invoke autom4te.
am_autom4te_ver=`$AUTOM4TE --version | sed -n '1{s:.*) ::;p}'
AS_CASE([$am_autom4te_ver],
... do the matching ...
what is the first autoconf release that has the fix ?
-mike
signature.asc
Description: PGP signature
