[bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolution

Mike Frysinger <[email protected]> Sun, 15 Jan 2023 03:23:03 -0500

Newsgroups	gmane.comp.sysutils.automake.patches
Message-ID	<Y8O357kzFtrIo9qe@vapier>

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 (application/pgp-signature, 833 B)