[sr #110319] autoconf incompatible change not fixed by autoupdate

[Zack Weinberg]

Update of sr #110319 (project autoconf):

                  Status:                    None => Invalid                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

I confirm the problem, but unfortunately there's nothing we can do to fix it.

Your second snippet is correct and is how the arguments to AS_IF should always
have been quoted (see the "M4 Quotation" section of the manual).

In your first snippet, AC_CHECK_PROG is expanded before AS_IF is expanded.  In
2.69c, the expansion of AC_CHECK_PROG contains a shell 'case' statement and
therefore an unbalanced close parenthesis.  M4 thinks that close parenthesis
is supposed to end the argument list of AS_IF, and so the expansion of AS_IF
puts a `fi` in the middle of the expansion of AC_CHECK_PROG.

In 2.69, AC_CHECK_PROG didn't expand to a construct containing a shell 'case'
statement.  It was introduced in commit
0eebfff3e04aae651b954cf98b97b5d382f3f230 as a bug fix for problems with
absolute paths starting with // on cygwin.  Off the top of my head I can't
think of a way to get the same effect without using 'case' that doesn't
involve running subprocesses, and this particular construct gets used a whole
lot in autoconf scripts so I am inclined to say we need it not to run
subprocesses.

This is not the only way things can go wrong if the second argument to AS_IF
is not quoted, either.  For instance, if AC_CHECK_PROG happened to expand to a
construct containing a _comma_ that wasn't inside either square brackets or a
macro argument list, the expansion would be understood as _multiple_ arguments
to AS_IF.

autoupdate cannot fix this because autoupdate can only replace obsolete
_macros_.  It can't do anything about improper quotation.

I will make the existing note about improper quotation in NEWS more explicit
but beyond that, again, there's nothing we can do.  Sorry.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110319>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/