Re: Fix sed script reading maint.mk.

2008-12-08 Thread Jim Meyering
Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello all, > > OK to apply? Or would you rather have the $(srcdir)/ in $(ME)? Hi Ralf, That's fine by me, modulo the long line. How about splitting it? syntax-check-rules := \ $(shell sed -n 's/^\(sc_[a-zA-Z0-9_-]*\):.*/\1/p' $(MYSELF)) I have a

Re: fts: expose dirent.d_type data when possible

2008-12-08 Thread Jim Meyering
Simon Josefsson <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >> Thanks for the report. >> How about this? > > Works fine here, thanks! Thanks for the confirmation. Pushed.

Re: putenv with mingw32

2008-12-08 Thread Simon Josefsson
Sylvain Beucler <[EMAIL PROTECTED]> writes: > On Sun, Dec 07, 2008 at 04:11:34PM -0800, Ben Pfaff wrote: >> Brian Dessent <[EMAIL PROTECTED]> writes: >> >> > MinGW implements access to 'environ' as a macro in stdlib.h, one which >> > gets the environment pointer through a function call. However,

Re: fts: expose dirent.d_type data when possible

2008-12-08 Thread Simon Josefsson
Jim Meyering <[EMAIL PROTECTED]> writes: > Thanks for the report. > How about this? Works fine here, thanks! /Simon

Add missing include to parse-duration.c.

2008-12-08 Thread Ralf Wildenhues
Hello Bruce, ok to commit? Seems pretty obvious. Thanks, Ralf Add missing include to parse-duration.c. * lib/parse-duration.c: #include "xalloc.h", for xstrdup. diff --git a/lib/parse-duration.c b/lib/parse-duration.c index 6487ba0..4c28349 100644 --- a/lib/parse-duration.c +++ b/

Fix sed script reading maint.mk.

2008-12-08 Thread Ralf Wildenhues
Hello all, OK to apply? Or would you rather have the $(srcdir)/ in $(ME)? Thanks, Ralf Fix sed script reading maint.mk. * top/maint.mk (MYSELF): New macro, define as $(srcdir)/$(ME). (syntax-check-rules): Use it. diff --git a/top/maint.mk b/top/maint.mk index 3756ee8..6d2ac03

Re: signbitl on powerpc-apple-darwin8.11.0

2008-12-08 Thread Bruno Haible
Simon Josefsson wrote: > Building gnulib (vasnprintf.c) on this platform (Mac OS X 10.4 fully > updated) results in: > > /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols: > _signbitl > collect2: ld returned 1 exit status > > Configure finds this: > > configure:79962: checking f

Re: special characters in filenames in error messages

2008-12-08 Thread Bruno Haible
Karl Berry wrote: > Therefore, when you deal with an URI, you should use a different > algorithm of presentation within a GNU error message than when you > deal with a filename. > > This seems like it adds complexity both in the description and in > comprehension. The long description

Re: special characters in filenames in error messages

2008-12-08 Thread Karl Berry
Therefore, when you deal with an URI, you should use a different algorithm of presentation within a GNU error message than when you deal with a filename. This seems like it adds complexity both in the description and in comprehension. At least I am having trouble with it -- it seems l

Re: [PATCH] warnings: Add gl_WARN_COMPLEMENT and gl_WARN_SUPPORTED.

2008-12-08 Thread Bruno Haible
Karl Berry wrote: > Wow, that is a great list. A lot of it does not seem gettext-specific? Yes, probably 80% of that list can also be disabled on other C packages. > Maybe it would be worth putting the description of all these warnings > you have researched into the manual? Before doing that, I

Re: putenv with mingw32

2008-12-08 Thread Sylvain Beucler
On Sun, Dec 07, 2008 at 04:11:34PM -0800, Ben Pfaff wrote: > Brian Dessent <[EMAIL PROTECTED]> writes: > > > MinGW implements access to 'environ' as a macro in stdlib.h, one which > > gets the environment pointer through a function call. However, that > > macro is not enabled if __STRICT_ANSI__ i

assert module and --enable-assert

2008-12-08 Thread Eric Blake
William Pursell astutely noticed that autoconf's AC_HEADER_ASSERT (added in 2.60) treats --enable-assert as a synonym for --disable-assert. It is now fixed in autoconf.git, so I'm applying the same fix to gnulib (we have to continue using m4/assert.m4 until such time as all gnulib projects assu

Re: fts: expose dirent.d_type data when possible

2008-12-08 Thread Jim Meyering
Simon Josefsson <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> +case DT_LNK: >> + type = S_IFLNK; >> + break; > ... >> +case DT_SOCK: >> + type = S_IFSOCK; >> + break; > > This patch causes mingw failures: > > fts.c: In function 'set_stat_type

Re: [PATCH] warnings: Add gl_WARN_COMPLEMENT and gl_WARN_SUPPORTED.

2008-12-08 Thread Karl Berry
The list of warnings that I would disable unconditionally would be: Wow, that is a great list. A lot of it does not seem gettext-specific? Maybe it would be worth putting the description of all these warnings you have researched into the manual? Thanks, karl

two tiny changes

2008-12-08 Thread Jim Meyering
I'll push these pretty soon. >From 8cac94365d8b5e8fb84089cb90523adcfb96fb71 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Tue, 2 Dec 2008 17:29:25 +0100 Subject: [PATCH 1/2] * build-aux/announce-gen (get_tool_versions): Accept .xz tarballs. --- build-aux/announce-gen |

[PATCH] posixtm.c: avoid a warning

2008-12-08 Thread Jim Meyering
FYI, I remove the following if-lint code, since it is no longer needed (with gcc4), and in fact would provoke its own warning. >From 37bc76801091560c6f1be54925d2942c0f66912a Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Sun, 7 Dec 2008 18:47:02 +0100 Subject: [PATCH] posixt

Re: fts: expose dirent.d_type data when possible

2008-12-08 Thread Simon Josefsson
Jim Meyering <[EMAIL PROTECTED]> writes: > +case DT_LNK: > + type = S_IFLNK; > + break; ... > +case DT_SOCK: > + type = S_IFSOCK; > + break; This patch causes mingw failures: fts.c: In function 'set_stat_type': fts.c:1035: error: 'S_IFLNK' undeclared (first use in thi

Re: config.status: error: ../../gltests/GNUmakefile: file not found

2008-12-08 Thread Simon Josefsson
Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson and Ralf Wildenhues wrote on 2008-11-29: >> > I'd prefer the latter (I don't think GNUmakefile belongs in >> > non-top-level directories) but don't know how to achieve it. >> >> Thanks for checking; I agree with the analysis, and that glt