Bruno Haible wrote: > Hi Jim, > >> - dnl Work around a bug of AC_EGREP_CPP in autoconf-2.57. >> - AC_REQUIRE([AC_PROG_CPP]) >> - AC_REQUIRE([AC_PROG_EGREP]) >> - >> AC_CACHE_CHECK([whether <inttypes.h> defines strtoimax as a macro], >> gl_cv_func_strtoimax_macro, >> [AC_EGREP_CPP([inttypes_h_defines_strtoimax], [#include <inttypes.h> > > I don't see the sense of this patch.
Why work around a bug in 2.57 when we now require 2.59? The proposed patch is solely clean-up on the gnulib side. As the subject implies, initially I thought this was the solution to the grep-configure problem. However, as you can see from what I wrote below, we can't eliminate AC_EGREP_CPP, so the requirement for something grep-like (however minimal) must remain. > - If it eliminates the expansion of AC_PROG_EGREP from the configure script, > the AC_EGREP_CPP expansion will contain an invalid command (namely > $EGREP something, and $EGREP expands to empty). > - If it does not eliminate the expansion of AC_PROG_EGREP from the configure > script, the error "checking for grep that handles long lines and -e... > configure: error: noa cceptable grep could be found" will still occur. > > In my test, with autoconf-2.68 and a testdir of the module list > "alloca dirfd strtoimax strtoumax", the expansion of AC_PROG_EGREP was still > present in the configure script - because autoconf nowadays contains a > dependency from AC_EGREP_CPP to AC_PROG_EGREP. > >> Unfortunately, some check for grep *is* required, >> since it's used here, to set EGREP >> >> ac_cv_path_EGREP="$GREP -E" >> EGREP="$ac_cv_path_EGREP" >> >> and $EGREP is used for each expansion of AC_EGREP_CPP, e.g., >> >> $ grep '\$EGREP' configure >> if test -z "$EGREP"; then >> ac_cv_path_EGREP=$EGREP >> $EGREP "memchr" >/dev/null 2>&1; then : >> $EGREP "free" >/dev/null 2>&1; then : >> $EGREP "webecray" >/dev/null 2>&1; then : >> $EGREP "choke me" >/dev/null 2>&1; then : >> $EGREP "booboo" >/dev/null 2>&1; then : >> $EGREP "yes" >/dev/null 2>&1; then : >> $EGREP "yes" >/dev/null 2>&1; then : >> >> However, each and every one of those uses is trivial > > Indeed, and this leads to a solution that actually works. You don't need > to get rid of the expansions of AC_PROG_GREP and AC_PROG_EGREP. It is > sufficient to note that the one of AC_PROG_GREP starts with > > if test -z "$GREP"; then > > and the one of AC_PROG_EGREP starts with > > if test -z "$EGREP"; then Thanks. I saw those, but you still need a grep-like program that does not invoke "grep". > Hence, it is possible to disable the body of these two expansions by > assigning values to GREP and EGREP inside the configure script. > > Here's how it works: > > 1) Store in build-aux/dummygrep the following file: > ============================= build-aux/dummygrep > ============================= > #!/bin/sh > # This file is a dummy replacement for the 'grep' command, solely for the > # use by GNU grep's configure command. > # It does not handle regular expressions with anchors or grouping, nor > # does it handle long lines in the input. But that is OK, since the only > # regular expressions that are passed by GNU grep's configure script are > # "choke me", "booboo", "yes", and similar. > > if test "X$1" = "X-e"; then > shift > fi > exec grep "$@" But with no grep program already installed, that will always fail.
