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
On Sun, Nov 14, 2010 at 05:31:25PM +0100, Paolo Bonzini wrote:
> Florin, can you try building GNU sed and see if it has a similar problem?
The released (4.2) version?
[flo...@icarus sed-4.2]$ ./configure --prefix=/usr/local
checking for a BSD-compatible install... build-aux/install-sh -c
checking
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 ke
* 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 l
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 i
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
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
Date: Sun, 14 Nov 2010 17:43:28 +010
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 blame/gi
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
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 b
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 enoug
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
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
Date: Sat, 13 Nov 2010 21:05:46 -08
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 Sol
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
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 defines strtoimax as a macro],
>> gl_cv_func_strtoimax_macro,
>> [AC_EGREP_CPP([inttypes_h_de
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 defines strtoimax as a macro],
> gl_cv_func_strtoimax_macro,
> [AC_EGREP_CPP([inttypes_h_defines_strtoimax], [#include
17 matches
Mail list logo
