[PATCH] top/maint.mk (indent): Run twice to produce idempotent results.

2010-04-28 Thread Simon Josefsson
I've pushed this. It appears to be a well known problem that GNU Indent is not idempotent when run once on code, but it appears to be idempotent when run twice. This is a maintainer target, so performance should not be a significant factor (and running indent on even large projects is quite fast

Re: replacement header licenses

2010-04-28 Thread Ben Pfaff
Eric Blake writes: > Paul, Ben; > > are you okay with gnulib's replacement for inttypes.h and math.h being > under LGPLv2+? It is fine with me. -- "doe not call up Any that you can not put downe." --H. P. Lovecraft

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

2010-04-28 Thread Jim Meyering
Bruno Haible wrote: > Jim Meyering wrote: >> You're welcome to push that. > > Pushed it. > >> I noticed that it provides the additional benefit >> of making the generated getdate.c file read-only. > > Huh? It does not do that for me, in a testdir made with > "gnulib-tool --create-testdir". I guess

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

2010-04-28 Thread Bruno Haible
Jim Meyering wrote: > You're welcome to push that. Pushed it. > I noticed that it provides the additional benefit > of making the generated getdate.c file read-only. Huh? It does not do that for me, in a testdir made with "gnulib-tool --create-testdir". I guess you have something in the coreutil

Re: [PATCH 2/4] Avoid an utimes(2) warning

2010-04-28 Thread Eric Blake
On 04/27/2010 06:35 PM, Bruno Haible wrote: >> I know that utimes() is affected. > > Aha! Now we're at the root of the problem: There is a portability problem > with utimes(), which causes a warning in utimens.c. > > But since utimes() already has so many other problems, we are recommending > to

[PATCH] canonicalize-lgpl: avoid compiler warning

2010-04-28 Thread Eric Blake
* lib/canonicalize-lgpl.c (versioned_symbol): Avoid an 'empty declaration' / 'extraneous semicolon' warning with some compilers. Reported by Andreas Gruenbacher. Signed-off-by: Eric Blake --- On further thought, here's an even smaller patch that does the same thing, and makes the diff to glibc l

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

2010-04-28 Thread Jim Meyering
Bruno Haible wrote: > Here's a proposed patch. It takes care to > - create getdate.c in the source directory, > - put into getdate.c #line statements that refer to "getdate.c", i.e. > don't depend on $(srcdir), > - use all Makefile variables that the automake generated .y.c rule would >

Re: replacement header licenses

2010-04-28 Thread Eric Blake
On 04/28/2010 03:09 AM, Bruno Haible wrote: > Eric Blake wrote: >> The following replacement headers are all under LGPL instead of LGPLv2+ >> licensing. Any objection to relaxing them, so that projects like >> libvirt can use all the replacement headers for things like >> GNULIB_POSIXCHECK or pass

Re: replacement header licenses

2010-04-28 Thread Paolo Bonzini
On 04/28/2010 11:09 AM, Bruno Haible wrote: Eric Blake wrote: The following replacement headers are all under LGPL instead of LGPLv2+ licensing. Any objection to relaxing them, so that projects like libvirt can use all the replacement headers for things like GNULIB_POSIXCHECK or passing Jim's r

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

2010-04-28 Thread Bruno Haible
Daniel Richard G. wrote: > I would suggest unconditionally qualifying the generated source > filenames with $(srcdir). Ralf Wildenhues wrote: > Prepending all files generated in the source tree with $(srcdir)/ > usually works. Last time we discussed this, on 2009-05-03,

Re: replacement header licenses

2010-04-28 Thread Bruno Haible
Eric Blake wrote: > The following replacement headers are all under LGPL instead of LGPLv2+ > licensing. Any objection to relaxing them, so that projects like > libvirt can use all the replacement headers for things like > GNULIB_POSIXCHECK or passing Jim's recent maint.mk syntax check? You need

Re: [PATCH 3/4] Avoid a stupid 'const object should have initializer' warning

2010-04-28 Thread Bruno Haible
Simon Josefsson wrote: > Isn't > > static relative_time const RELATIVE_TIME_0 = { }; > > equivalent too? I find that is a nice idiom. This syntax is not portable. Sun C, for example, does not like it: $ cat foo.c typedef struct { /* Relative year, month, day, hour, minutes, seconds, and nano

[PATCH] init.sh: ensure a more reliable exit status when exiting via trap

2010-04-28 Thread Jim Meyering
I've fixed the trap code in init.sh. Thanks, Dmitry. >From 092a81622804491f13fb73f4df610db0db45b35a Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 28 Apr 2010 09:51:15 +0200 Subject: [PATCH] init.sh: ensure a more reliable exit status when exiting via trap * tests/init.sh (setup_): Don'

Re: [PATCH 3/4] Avoid a stupid 'const object should have initializer' warning

2010-04-28 Thread Simon Josefsson
Eric Blake writes: > On 04/27/2010 03:24 PM, Andreas Gruenbacher wrote: >> * lib/getdate.y (RELATIVE_TIME_0): Avoid a stupid 'const object should >> have initializer' warning. >> >> @@ -152,7 +152,7 @@ typedef struct >> #if HAVE_COMPOUND_LITERALS >> # define RELATIVE_TIME_0 ((relative_time) {

Re: replacement header licenses

2010-04-28 Thread Simon Josefsson
Eric Blake writes: > The following replacement headers are all under LGPL instead of LGPLv2+ > licensing. Any objection to relaxing them, so that projects like > libvirt can use all the replacement headers for things like > GNULIB_POSIXCHECK or passing Jim's recent maint.mk syntax check? > > fcn

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

2010-04-28 Thread Daniel Richard G.
On Wed, 2010 Apr 28 07:45+0200, Ralf Wildenhues wrote: > > Prepending all files generated in the source tree with $(srcdir)/ > usually works. One has to note though that it really needs to be done > in every place, ie., als EXTRA_DIST, and bits which might be generated > by automake. Automake alr