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],
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,
Jim Meyering wrote:
While the dependency of AC_EGREP_CPP on AC_PROG_EGREP
is unavoidable, there are others that are indeed unnecessary,
since they serve only to work around a bug in autoconf-2.57,
which is no longer relevant, since we (gnulib-tool) now
requires 2.59 or newer.
...
Now we
Hi Jim,
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.
As a pure clean-up patch, it is OK. But you confused me completely
by proposing it under the subject grep fails to build on
I finally got around to testing the final version of the fix. It
works fine. Thanks to everyone for advice.
Here's the final version of the patch for review.
Thanks,
Ben.
--8--cut here--8--
From: Ben Pfaff b...@cs.stanford.edu
Date: Sat, 13
Bruno Haible wrote:
Jim Meyering wrote:
While the dependency of AC_EGREP_CPP on AC_PROG_EGREP
is unavoidable, there are others that are indeed unnecessary,
since they serve only to work around a bug in autoconf-2.57,
which is no longer relevant, since we (gnulib-tool) now
requires 2.59 or
On 11/14/2010 03:09 PM, Jim Meyering wrote:
It is possible to disable the body of these two expansions by
assigning values to GREP and EGREP inside the configure script.
But with no grep program already installed, that will always fail.
You can implement a basic grep that is good enough for
Paolo Bonzini wrote:
On 11/14/2010 03:09 PM, Jim Meyering wrote:
It is possible to disable the body of these two expansions by
assigning values to GREP and EGREP inside the configure script.
But with no grep program already installed, that will always fail.
You can implement a basic grep
Paolo Bonzini wrote:
+# Override grep during configure.
+fn_grep () {
I would suggest more comments.
- What is the purpose of this override?
- What are its limitations?
10 years from now, no one will remember.
Suggestion:
# Set the GREP and EGREP variables to a dummy replacement for the
On 11/14/2010 05:25 PM, Bruno Haible wrote:
Paolo Bonzini wrote:
+# Override grep during configure.
+fn_grep () {
I would suggest more comments.
- What is the purpose of this override?
- What are its limitations?
10 years from now, no one will remember.
True, but there is git
I searched for a project that overrides this noteworthy definition,
but found none. So I've renamed the variable to start with gl_,
and to be a little more descriptive:
From 321fd42fee5eb894decb2b8de93698071fac3c29 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 14 Nov
On 2010-10-12 I wrote:
I think this and the two other modifications I mentioned in the
other mail - dealing with include_next and old compilers, and handling of
typedefs and struct definitions in the *.in.h files - should be dealt with
at the same time.
'struct random_data' in stdlib.in.h was
On 11/14/2010 06:48 PM, Florin Iucha wrote:
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking how to run the C preprocessor... cc -E
checking for grep that handles long lines and -e... configure: error: no
acceptable grep could be found
* Paolo Bonzini wrote on Sun, Nov 14, 2010 at 08:09:12PM CET:
On 11/14/2010 06:48 PM, Florin Iucha wrote:
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking how to run the C preprocessor... cc -E
checking for grep that handles long
Hi,
On Mon, 18 Oct 2010, Paul Eggert wrote:
How about another idea: have a very simple bootstrap script. All it
does is fetch gnulib, and execute gnulib's more-complicated script.
After seeing a few more bootstrap patches go through, I'm motivated to
revisit this idea again.
To keep
On 11/14/2010 03:22 PM, Joel E. Denny wrote:
To keep things simple, could we just extend the existing bootstrap script
so that, once it has fetched gnulib sources and before doing anything
else, it updates itself and re-exec's itself if there are any changes?
It sounds tricky to update a
16 matches
Mail list logo
