[sr #110312] 2.69b: broken AC_PROG_LEX macro

2020-09-26 Thread Zack Weinberg
Update of sr #110312 (project autoconf):

  Status:None => Need Info  

___

Follow-up Comment #7:

I cannot reproduce the problem with this configure.ac:


AC_INIT([bug-110312], [1.0])
AC_PROG_LEX
AC_OUTPUT


It prints "checking for lex library... none needed" regardless of whether
libl.a or libfl.so is present on the system.  In fact, it says the same thing
even if *none* of the lib{f,}l.* files that my system usually has are
available.  There must be something else going on.

I'm going to need that minimal configure.ac I asked for on Thursday, and I'm
also going to need the config.log produced when you run it on your system.

___

Reply to this item at:

  

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




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

2020-09-26 Thread 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:

  

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