Please don't top-post on this mailing list.
On Tue, Mar 28, 2023, at 1:29 PM, Frederic Berat wrote:
On Tue, Mar 28, 2023 at 7:04 PM Nick Bowler <nbowler@draconx.ca> wrote:
On 2023-03-28, Zack Weinberg <zack@owlfolio.org> wrote:
Can someone who understands the problem described at
https://lists.gnu.org/archive/html/autoconf/2022-11/msg00129.html
please construct a minimal, self-contained configure.ac that
reproduces that problem?
This should be a good approximation:
...
That's close enough, yes. You actually don't need the "else" though, it's
enough to isolate the first call to egrep:
% cat >configure.ac <<'EOF'
AC_INIT([test], [0])
AC_PROG_CPP
AC_PROG_EGREP
# uncomment to make this work on new autoconf
# m4_ifdef([_AC_PROG_EGREP_TRADITIONAL], [_AC_PROG_EGREP_TRADITIONAL])
if false; then
AC_EGREP_HEADER([printf], [stdio.h])
fi
AC_MSG_CHECKING([if stuff works])
AC_EGREP_HEADER([malloc], [stdlib.h],
[AC_MSG_RESULT([ok])], [AC_MSG_RESULT([nope])])
OK, I understand the issue now. _AC_PROG_EGREP_TRADITIONAL is actually
quite new (introduced in 0c762675, last June, post-2.71) and the idea
seems to have been that AC_PROG_EGREP is quite picky -- it insists on
finding an implementation that supports long lines and the -e option
(not to be confused with the -E option) -- but AC_EGREP_CPP and
AC_EGREP_HEADER can probably get away with using an egrep that doesn't
support these things. But, AC_PROG_EGREP doesn't do the fallback check
for a more limited egrep; that code is only emitted on the first actual
use of AC_EGREP_HEADER, which in this case is inside the 'if false'.
This configure.ac *is* incorrect, but since we are trying to make
2.73 a smooth upgrade from 2.71 I do think we should keep it working,
and the obvious way to do that is to fold the "fallback check for a
more limited egrep" into AC_PROG_EGREP. Any objections to that
change? If not, I'll send a patch in a day or two.
OpenPGP_0xBB053355919D3314.asc