Re: double-include include_next fix for Solaris 8, Sun Studio 11

Paul Eggert wrote: > The problem is that Solaris 8 eventually includes itself > recursively. ... > > I installed the following patch, which fixes the problem for Solaris 8. Yes, it looks like a viable solution when a system header includes itself. The other solution would have been to add more #

Re: double-include include_next fix for Solaris 8, Sun Studio 11

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 6/23/2007 2:01 PM: > I installed the following patch, which fixes the problem for Solaris > 8. I don't have easy access to mingw, but if this idea also works on > mingw then perhaps we should use a similar solution for the

Re: gnulib-tool nits

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/23/2007 1:09 PM: > But then use IFS (so that PATH elements containing spaces are handled > correctly), ignoring empty fields from the cases C and D. In summary, > something like this: > > pathx=`echo ":$PATH:" | sed -e

double-include include_next fix for Solaris 8, Sun Studio 11

I ran into a problem with gnulib on Solaris 8 with Sun Studio 11, which resulted from the combination of the double-include patch of and the recent #include_next patch of

Re: rmdir sys || exit 0?

Karl Berry wrote: > I find that make clean fails for me in texinfo's gnulib, because my > gnulib/lib/sys/ directory is not empty, just because it contains a CVS dir: > > $ make clean > ... > make[1]: Entering directory `/u/karl/gnu/src/texinfo/gnulib/lib' > test -z "" || rm -f > test -z "libgnu.a

Re: gnulib-tool nits

Hi Ralf. > This isn't reliable either: bash 3.1.17 and ksh do this: > $ ( d=:a:b:; IFS=:; for i in $d ; do echo .$i. ; done ) > .. > .a. > .b. > > but pdksh does this: > $ ( d=:a:b:; IFS=:; for i in $d ; do echo .$i. ; done ) > .. > .a. > .b. > .. This is only the tip of the iceberg. I tested al

rmdir sys || exit 0?

I find that make clean fails for me in texinfo's gnulib, because my gnulib/lib/sys/ directory is not empty, just because it contains a CVS dir: $ make clean ... make[1]: Entering directory `/u/karl/gnu/src/texinfo/gnulib/lib' test -z "" || rm -f test -z "libgnu.a" || rm -f libgnu.a test -z "" ||

Re: gnulib-tool nits

* Ralf Wildenhues wrote on Sat, Jun 23, 2007 at 03:18:49PM CEST: > +IFS=: > +for d in $PATH:; do This isn't reliable either: bash 3.1.17 and ksh do this: $ ( d=:a:b:; IFS=:; for i in $d ; do echo .$i. ; done ) .. .a. .b. but pdksh does this: $ ( d=:a:b:; IFS=:; for i in $d ; do echo .$i.

Re: gnulib-tool nits

Hello Bruno, * Bruno Haible wrote on Sat, Jun 23, 2007 at 02:53:41PM CEST: > Ralf Wildenhues wrote: > > Another rough pass over gnulib-tool's tendency to spawn more processes > > than it needs to. > > Why not. But why don't you concentrate on the loops of func_import when > doing that? gnulib-too

Re: gnulib-tool nits

Ralf Wildenhues wrote: > Another rough pass over gnulib-tool's tendency to spawn more processes > than it needs to. Why not. But why don't you concentrate on the loops of func_import when doing that? gnulib-tool will not become measurably faster by optimizing code that is executed only once. >

Re: Bug in gnulib-tools prevents bison from bootstrapping

Eric Blake wrote: > Since forking external programs matters most on cygwin and mingw ... Also on AIX, HP-UX, IRIX, OSF/1, Solaris, one can avoid spawning 'cat': by using the 'print -r' trick from libtool.m4. 2007-06-23 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (echo): Add a speed

Re: Bug in gnulib-tools prevents bison from bootstrapping

Paul Eggert wrote: > I think printf is portable nowadays, at least to the platforms that > gnulib-tool is likely to run on. Indeed, 'printf' is useful to use when we find that it is a shell built-in, namely on bash >= 2.0. (See the patch in the other mail.) But other than that? 'printf' is portab

Re: Bug in gnulib-tools prevents bison from bootstrapping

Eric Blake wrote: > POSIX requires that echo interpret backslash sequences. POSIX:2001 Technical Corrigendum 1 [1] mentions that BSD echo is POSIX compliant. Eric Blake and Paul Eggert wrote: > POSIX even admits this, and recommends the use of printf instead. > ... > One advantage of using printf

Re: Bug in gnulib-tools prevents bison from bootstrapping

On 23 Jun 2007, at 06:25, Eric Blake wrote: If you reconfigured autoconf after installing a newer GNU m4, and autoconf did not find the right m4, then that is a bug in autoconf, and should be dealt with there. Right. Since it was experienced by the developers on the Bug-Bison list, I hop

Re: Bug in gnulib-tools prevents bison from bootstrapping

On Fri, 2007-06-22 at 14:48 +0200, Hans Aberg wrote: > On 22 Jun 2007, at 14:27, Fernando Ferreira wrote: > > >> Autoconf requires the latest m4, but it actually calls gm4 it > >> seems. So I installed the latest M4, which ended up in /usr/local/ > >> bin/m4 on my system, and added a soft link

Re: Bug in gnulib-tools prevents bison from bootstrapping

Bruno Haible <[EMAIL PROTECTED]> writes: > libtool.m4 also tries other workarounds: searching for an 'echo' program > in $PATH:/usr/ucb (but how is this better than 'cat'?) or using a built-in > 'print -r' command (which shells except ksh have this?) or using 'printf' > (is that portable nowadays?

Re: gnulib-tool nits

Hello Paul, * Paul Eggert wrote on Fri, Jun 22, 2007 at 11:43:00PM CEST: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > + if test -z "$self_abspathname"; then > > self_abspathname should be initialized to the empty string, for this > test to work reliably (this problem is present in the cu

Re: Bug in gnulib-tools prevents bison from bootstrapping

Eric Blake <[EMAIL PROTECTED]> writes: > POSIX requires that echo interpret backslash sequences. Actually, POSIX says that the behavior of 'echo' is implementation-defined if any of the arguments contain backslash, or if echo's first operand is -n. If the implementation supports the XSI extensio

include_next fixes for Sun Studio 11 on Solaris 8

I had some in-hindsight-obvious typos in my recent include_next patches, which were exposed by Sun Studio 11 on Solaris 8. They would also occur on other non-include_next C compilers. I installed the following to fix the bugs: 2007-06-23 Paul Eggert <[EMAIL PROTECTED]> * m4/include_ne