[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolutio
From: |
Mike Frysinger |
Subject: |
[bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolution |
Date: |
Sun, 15 Jan 2023 03:23:03 -0500 |
On 14 Jan 2023 21:43, Jacob Bachmeyer wrote:
> Mike Frysinger wrote:
> > --- a/t/aclocal-no-force.sh
> > +++ b/t/aclocal-no-force.sh
> > @@ -19,6 +19,18 @@
> >
> > . test-init.sh
> >
> > +# Automake relies on high resolution timestamps in perl. If support isn't
> > +# available (see lib/Automake/FileUtils.pm), then fallback to coarse
> > sleeps.
> > +# The creative quoting is to avoid spuriously triggering a failure in
> > +# the maintainer checks.
> > +case ${sleep_delay} in
> > +0*)
> > + if ! $PERL -e 'use Time::HiRes' 2>/dev/null; then
> > + sleep='sleep ''2'
> > + fi
> > + ;;
> > +esac
> > +
>
> I seem to remember being told that "if !" is non-portable. Is there
> some other mechanism that ensures this is always run with Bash or might
> "if $PERL ... ; then :; else" be a better option for that line?
you're right:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Limitations-of-Builtins.html
i'll note that Automake tests have been using `if ! ...` since 1.12 (2012),
and no one seems to have complained. further, the shell we're using here is
the one autoconf and/or we detected, so it should avoid older broken ones.
i'm inclined to not bend over backwards for this.
> Also, you could write that Perl command as "$PERL -MTime::HiRes -e 1
> 2>/dev/null" and avoid needing any quotes there, although I suspect this
> is simply a matter of style and the comment refers to the quotes when
> setting $sleep.
yes, the quoting comment is referring to the sleep statement. i can clarify
in the comment by referring to "sleep".
> You could also exploit that || short-circuits in the shell and replace
> the "if" block with " $PERL ... || sleep='sleep ''2' ". This allows you
> to directly execute a command on a false result and (I think) it is
> portable, too. (I half-expect someone to correct me on that along the
> lines of "the shell on Obscurix has a bug where || implicitly uses a
> subshell".)
personally i find (ab)use of `||` and `&&` tends to lead to unmaintainable code.
i.e. it tends to produce write-once-read-never code akin to most perl. so if
the construct has been in use already and isn't causing issues, i'd use it.
-mike
signature.asc
Description: PGP signature