bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #31646] grep fails to build on Solaris 10, because it lacks gre


From: Jim Meyering
Subject: Re: [bug #31646] grep fails to build on Solaris 10, because it lacks grep
Date: Sun, 14 Nov 2010 15:09:40 +0100

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]