Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Eli Zaretskii]

> diff --git a/configure.ac b/configure.ac
> index 855c4ec7df1..f63eb870ffb 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1664,7 +1664,7 @@ AC_ARG_ENABLE([gcc-warnings],
>     # however, if there is also a .tarball-version file it is probably
>     # just a release imported into Git for patch management.
>     gl_gcc_warnings=no
> -   if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then
> +   if test -e "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then
>        # Clang typically identifies itself as GCC 4.2 or something similar
>        # even if it is recent enough to accept the warnings we enable.
>        AS_IF([test "$emacs_cv_clang" = yes],

According to the Autoconf manual, "test -e" is not portable to
Solaris.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Mattias Engdegård]

29 sep. 2023 kl. 20.07 skrev Eli Zaretskii <eliz@gnu.org>:

> According to the Autoconf manual, "test -e" is not portable to
> Solaris.

Thanks for noticing and yes, the Solaris man page for test(1) seems to agree.
I don't have a Solaris machine to test it on but pushed something that might work.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Po Lu]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> Thanks for noticing and yes, the Solaris man page for test(1) seems to agree.
> I don't have a Solaris machine to test it on but pushed something that might work.

test -o is equally non-portable.  I will fix that on master.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Mattias Engdegård]

30 sep. 2023 kl. 13.33 skrev Po Lu <luangruo@yahoo.com>:

> test -o is equally non-portable.  I will fix that on master.

The Solaris man page suggested that -o would work. Is it in error, or did I misread it?

https://docs.oracle.com/cd/E86824_01/html/E54763/test-1.html

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Po Lu]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 30 sep. 2023 kl. 13.33 skrev Po Lu <luangruo@yahoo.com>:
>
>> test -o is equally non-portable.  I will fix that on master.
>
> The Solaris man page suggested that -o would work. Is it in error, or did I misread it?
>
> https://docs.oracle.com/cd/E86824_01/html/E54763/test-1.html

It functions on Solaris, but not under other POSIX systems.
(autoconf)Limitations of Builtins mentions:

‘test’
     The ‘test’ program is the way to perform many file and string
     tests.  It is often invoked by the alternate name ‘[’, but using
     that name in Autoconf code is asking for trouble since it is an M4
     quote character.

     The ‘-a’, ‘-o’, ‘(’, and ‘)’ operands are not present in all
     implementations, and have been marked obsolete by Posix 2008.  This
     is because there are inherent ambiguities in using them.  For
     example, ‘test "$1" -a "$2"’ looks like a binary operator to check
     whether two strings are both non-empty, but if ‘$1’ is the literal
     ‘!’, then some implementations of ‘test’ treat it as a negation of
     the unary operator ‘-a’.

     Thus, portable uses of ‘test’ should never have more than four
     arguments, and scripts should use shell constructs like ‘&&’ and
     ‘||’ instead.  If you combine ‘&&’ and ‘||’ in the same statement,
     keep in mind that they have equal precedence, so it is often better
     to parenthesize even when this is redundant.  For example:

          # Not portable:
          test "X$a" = "X$b" -a \
            '(' "X$c" != "X$d" -o "X$e" = "X$f" ')'

          # Portable:
          test "X$a" = "X$b" &&
            { test "X$c" != "X$d" || test "X$e" = "X$f"; }

     ‘test’ does not process options like most other commands do; for
     example, it does not recognize the ‘--’ argument as marking the end
     of options.

     It is safe to use ‘!’ as a ‘test’ operator.  For example, ‘if test
     ! -d foo; ...’ is portable even though ‘if ! test -d foo; ...’ is
     not.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Mattias Engdegård]

30 sep. 2023 kl. 13.54 skrev Po Lu <luangruo@yahoo.com>:

> It functions on Solaris, but not under other POSIX systems.

So it does work everywhere in practice. That's good to know.
Feel free to modify the code as you like, as long as it still works.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Po Lu]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> So it does work everywhere in practice. That's good to know.

Please do not treat this as a justification to introduce more instances
of this non-portable construct in the future!  It is mentioned within
the Autoconf manual precisely because it does not work everywhere, in
practice.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Mattias Engdegård]

30 sep. 2023 kl. 14.24 skrev Po Lu <luangruo@yahoo.com>:

> Please do not treat this as a justification to introduce more instances
> of this non-portable construct in the future!

Of course I'm not going to, but I can make use of the knowledge elsewhere.
Because of course it works. You won't find a counter-example that matters.
(And if think you do, reply to me privately; this is no longer an Emacs matter.)

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Björn Bidar]

Po Lu <luangruo@yahoo.com> writes:

W> Mattias Engdegård <mattias.engdegard@gmail.com> writes:
>
>> 30 sep. 2023 kl. 13.33 skrev Po Lu <luangruo@yahoo.com>:
>>
>>> test -o is equally non-portable.  I will fix that on master.
>>
>> The Solaris man page suggested that -o would work. Is it in error, or did I misread it?
>>
>> https://docs.oracle.com/cd/E86824_01/html/E54763/test-1.html
>
> It functions on Solaris, but not under other POSIX systems.
> (autoconf)Limitations of Builtins mentions:
>
> ‘test’
>      The ‘test’ program is the way to perform many file and string
>      tests.  It is often invoked by the alternate name ‘[’, but using
>      that name in Autoconf code is asking for trouble since it is an M4
>      quote character.
>
>      The ‘-a’, ‘-o’, ‘(’, and ‘)’ operands are not present in all
>      implementations, and have been marked obsolete by Posix 2008.  This
>      is because there are inherent ambiguities in using them.  For
>      example, ‘test "$1" -a "$2"’ looks like a binary operator to check
>      whether two strings are both non-empty, but if ‘$1’ is the literal
>      ‘!’, then some implementations of ‘test’ treat it as a negation of
>      the unary operator ‘-a’.
>
>      Thus, portable uses of ‘test’ should never have more than four
>      arguments, and scripts should use shell constructs like ‘&&’ and
>      ‘||’ instead.  If you combine ‘&&’ and ‘||’ in the same statement,
>      keep in mind that they have equal precedence, so it is often better
>      to parenthesize even when this is redundant.  For example:
>
>           # Not portable:
>           test "X$a" = "X$b" -a \
>             '(' "X$c" != "X$d" -o "X$e" = "X$f" ')'
>
>           # Portable:
>           test "X$a" = "X$b" &&
>             { test "X$c" != "X$d" || test "X$e" = "X$f"; }
>
>      ‘test’ does not process options like most other commands do; for
>      example, it does not recognize the ‘--’ argument as marking the end
>      of options.
>
>      It is safe to use ‘!’ as a ‘test’ operator.  For example, ‘if test
>      ! -d foo; ...’ is portable even though ‘if ! test -d foo; ...’ is
>      not.

The reference to the autoconf manual makes me wonder what would be the
cutoff point for older systems to support. Some of these systems are
quite ancient.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Mattias Engdegård <mattias.engdegard@gmail.com>,  Eli
>  Zaretskii
>  <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 30 Sep 2023 16:21:22 +0300
> 
> The reference to the autoconf manual makes me wonder what would be the
> cutoff point for older systems to support. Some of these systems are
> quite ancient.

From where I stand, as long as the Autoconf manual keeps warning about
this, we should not use it.  When the Autoconf folks decide to remove
it, we could revisit this issue and decide whether we can also use it,
depending on what system still have problems with it at that time.

Btw, the Autoconf manual here matters because the Gnu Coding Standards
document points to it as the "canonical" source of portability issues
that GNU projects should consider.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Po Lu]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> The reference to the autoconf manual makes me wonder what would be the
> cutoff point for older systems to support. Some of these systems are
> quite ancient.

Autoconf scripts should abide by each guideline within the Autoconf
manual irrespective of which systems they elect to support, for there is
always the possibility that a new system may emerge evincing bugs
comparable to those manifested by earlier ones, or that someone might
wish to transplant Emacs onto an older system; whereupon the configure
script ought to serve as assistance, not as an impediment.

In this particular case, all Unix systems (back to Version 7 Unix)
support `test -o'.  Non-XSI POSIX shells might not, and such shells do
exist or may exist in the future.  Moreover, `test -o' suffers from
inherent ambiguities that render it unreliable under circumstances that
are difficult to detect, so it is better to forestall such errors by
eschewing `test -o' uniformly.

Re: master a89c86888c4 1/3: Detect developer builds in git worktrees as well

[Andreas Schwab]

On Sep 30 2023, Mattias Engdegård wrote:

> 30 sep. 2023 kl. 13.33 skrev Po Lu <luangruo@yahoo.com>:
>
>> test -o is equally non-portable.  I will fix that on master.
>
> The Solaris man page suggested that -o would work. Is it in error, or did I misread it?

POSIX marks it as obsolescent.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."