Re: m4/inttypes.m4: announce test + caching

2006-11-14 Thread Paul Eggert
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > 2006-11-14 Ralf Wildenhues <[EMAIL PROTECTED]> > > * m4/inttypes.m4 (gl_INTTYPES_H): Use AC_CACHE_CHECK so that the > test for conforming inttypes.h is both announced and cached. Thanks, I installed the following further change so that i

Re: [bug-gnulib] m4/inttypes.m4: announce test + caching

2006-11-14 Thread Ralf Wildenhues
* Bruno Haible wrote on Tue, Nov 14, 2006 at 11:00:30PM CET: > Ralf Wildenhues wrote: > > 2006-11-14 Ralf Wildenhues <[EMAIL PROTECTED]> > > > > * m4/inttypes.m4 (gl_INTTYPES_H): Use AC_CACHE_CHECK so that the > > test for conforming inttypes.h is both announced and cached. > > Looks go

Re: [bug-gnulib] speed up MODULES.html.sh a bit

2006-11-14 Thread Ralf Wildenhues
* Bruno Haible wrote on Tue, Nov 14, 2006 at 09:30:54PM CET: > > You also combined adjacent sed invocations. Which rule are you using here? > When is it safe to combine > sed -e "$expr1" | sed -e "$expr2" > into > sed -e "$expr1" -e "$expr2" > ? Erm, for example when all of the following

Re: [bug-gnulib] m4/inttypes.m4: announce test + caching

2006-11-14 Thread Bruno Haible
Ralf Wildenhues wrote: > 2006-11-14 Ralf Wildenhues <[EMAIL PROTECTED]> > > * m4/inttypes.m4 (gl_INTTYPES_H): Use AC_CACHE_CHECK so that the > test for conforming inttypes.h is both announced and cached. Looks good to me. Thanks! Bruno

Re: [bug-gnulib] speed up MODULES.html.sh a bit

2006-11-14 Thread Paul Eggert
Bruno Haible <[EMAIL PROTECTED]> writes: > You also combined adjacent sed invocations. Which rule are you using here? > When is it safe to combine > sed -e "$expr1" | sed -e "$expr2" > into > sed -e "$expr1" -e "$expr2" > ? That's a tricky question to answer in general, but if $expr1 and

Re: [bug-gnulib] speed up MODULES.html.sh a bit

2006-11-14 Thread Bruno Haible
Hello Ralf, > The patch below shaves a couple of minutes off of MODULES.html.sh's > roughly 5 minutes worth of execution time. Half of that is achieved > by not calling gnulib-tool more often than necessary, the other by > eliminating a couple of quadratic file list handlings. These are good tr

m4/inttypes.m4: announce test + caching

2006-11-14 Thread Ralf Wildenhues
What do you think of the following patch? This looks useful to me for nailing down an independent issue in lib/inttypes_.h: with this, it actually works to override the test temporarily with ./configure gl_cv_header_working_inttypes_h=yes (and thus decouple this from other build failures). Che

speed up MODULES.html.sh a bit

2006-11-14 Thread Ralf Wildenhues
Hello Bruno, all, The patch below shaves a couple of minutes off of MODULES.html.sh's roughly 5 minutes worth of execution time. Half of that is achieved by not calling gnulib-tool more often than necessary, the other by eliminating a couple of quadratic file list handlings. As shown, the scrip

Re: c-ctype, inttostr, intprops module license

2006-11-14 Thread Paul Eggert
Jim Meyering <[EMAIL PROTECTED]> writes: > inttostr.c is barely 20 lines of code, and pretty simple. > And each of the other .c files is just a 3-line stub. > Changing the module to LGPL is fine with me, but Paul's the owner. I should have also said: I changed it to LGPL.

Re: c-ctype, inttostr, intprops module license

2006-11-14 Thread Paul Eggert
Jim Meyering <[EMAIL PROTECTED]> writes: > inttostr.c is barely 20 lines of code, and pretty simple. > And each of the other .c files is just a 3-line stub. > Changing the module to LGPL is fine with me, but Paul's the owner. Fine with me too.

Re: [bug-gnulib] inline.m4: use compiler, not cpp

2006-11-14 Thread Paul Eggert
Bruno Haible <[EMAIL PROTECTED]> writes: > $ ./configure > $ make > $ make clean > $ make CFLAGS="-g -O0" > be trapped in the link error: xmalloc.c, compiled with optimization, will > not define xnmalloc, whereas the main sources, compiled without optimization, > will require it. How abou

Re: c-ctype, inttostr, intprops module license

2006-11-14 Thread Jim Meyering
Simon Josefsson <[EMAIL PROTECTED]> wrote: > Yoann Vandoorselaere <[EMAIL PROTECTED]> writes: >> The following modules are licensed under GPL but used by LGPL modules: >> >> - inttostr: used by getaddrinfo > > Ouch, this is serious, and was introduced recently. Jim, Paul, would > you agree to re-l

Re: some warnings in tests/

2006-11-14 Thread Simon Josefsson
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hello Simon, > > OK to apply? This makes tests/ 'gcc -Wall -Werror' proof. Hi Ralf! Looks good, please install it. /Simon > Cheers, > Ralf > > 2006-11-13 Ralf Wildenhues <[EMAIL PROTECTED]> > > * tests/test-gc.c (main): Remove unused varia

Re: [PATCH] Re: c-ctype, inttostr, intprops module license

2006-11-14 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Yoann Vandoorselaere on 11/14/2006 5:01 AM: > warning: module mkdtemp depend on another module with incompatible license: > tempname tempname was ripped straight from glibc, so I'm changing it to LGPL: 2006-11-14 Eric Blake <[EMAIL PR

Re: c-ctype, inttostr, intprops module license

2006-11-14 Thread Simon Josefsson
Yoann Vandoorselaere <[EMAIL PROTECTED]> writes: > Hi, > > The following modules are licensed under GPL but used by LGPL modules: > > - inttostr: used by getaddrinfo Ouch, this is serious, and was introduced recently. Jim, Paul, would you agree to re-license inttostr as LGPL? If you don't have

Re: [bug-gnulib] Question concerning c-ctype, c-strcase, c-strcasestr and c-strstr modules

2006-11-14 Thread Bruno Haible
Yoann Vandoorselaere wrote: > > I don't think Chinese users will find it nice if you exclude them from > > correct functioning of your program because of "performance" or "library > > size". > > I don't think you are qualified to decide in place of the application > developer whether the applicat

Re: missing dependencies [Re: inline.m4: use compiler, not cpp

2006-11-14 Thread Jim Meyering
Bruno Haible <[EMAIL PROTECTED]> wrote: > These are apparently triggered by the use of $(LIBOBJS) in coreutils' > lib/Makefile.am. Although it is a bit uncommon to combine pieces of > gnulib and different pieces from outside gnulib in the same library, I > think gnulib-tool should support this. > >

Re: [bug-gnulib] Re: [bug-gnulib] Re: Question concerning c-ctype, c-strcase, c-strcasestr and c-strstr modules

2006-11-14 Thread Bruno Haible
Yoann Vandoorselaere wrote: > "However, if we have a platform missing strcasestr, then using > c_strcasestr as the substitute implementation is probably okay, because > that platform would probably be broken in other areas, such as locale > support, ... Solaris 9 and Solaris 10 (which also doesn't

Re: [bug-gnulib] Question concerning c-ctype, c-strcase, c-strcasestr and c-strstr modules

2006-11-14 Thread Yoann Vandoorselaere
On Tue, 2006-11-14 at 13:38 +0100, Bruno Haible wrote: > Yoann Vandoorselaere wrote: > > "However, if we have a platform missing strcasestr, then using > > c_strcasestr as the substitute implementation is probably okay, because > > that platform would probably be broken in other areas, such as loca

Re: [bug-gnulib] Question concerning c-ctype, c-strcase, c-strcasestr and c-strstr modules

2006-11-14 Thread Yoann Vandoorselaere
On Tue, 2006-11-14 at 14:58 +0100, Bruno Haible wrote: > Yoann Vandoorselaere wrote: > > > I don't think Chinese users will find it nice if you exclude them from > > > correct functioning of your program because of "performance" or "library > > > size". > > > > I don't think you are qualified to

Re: [bug-gnulib] Re: Question concerning c-ctype, c-strcase, c-strcasestr and c-strstr modules

2006-11-14 Thread Bruno Haible
Yoann Vandoorselaere wrote: > Solaris 9 apparently lack the strcasestr() function. If the program needs strcasestr(), then it needs the 'strcasestr' module. It defines a replacement for strcasestr(). > Might we modify the > c-strcasestr module so that it provide a replacement for platform > lack

Re: c-ctype, inttostr, intprops module license

2006-11-14 Thread Bruno Haible
Yoann Vandoorselaere wrote: > The following modules are licensed under GPL but used by LGPL modules: > > - c-ctype: used by c-strcase, c-strcasestr, linebreak. I'm changing the copyright of c-ctype to LGPL: *** modules/c-ctype 22 Sep 2004 15:11:04 - 1.2 --- modules/c-ctype 14 No

Re: [bug-gnulib] Re: Question concerning c-ctype, c-strcase, c-strcasestr and c-strstr modules

2006-11-14 Thread Yoann Vandoorselaere
On Tue, 2006-11-14 at 11:40 +0100, Bruno Haible wrote: > Yoann Vandoorselaere wrote: > > Solaris 9 apparently lack the strcasestr() function. > > If the program needs strcasestr(), then it needs the 'strcasestr' module. > It defines a replacement for strcasestr(). > > > Might we modify the > > c

Cygwin now supports printf(%zu)

2006-11-14 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With today's release of cygwin 1.5.22, my patch to newlib to make *printf functions recognize the hh, ll, z, j, and t size modifiers is now supported by cygwin. I'm installing this. 2006-11-14 Eric Blake <[EMAIL PROTECTED]> * doc/functions

[PATCH] Re: c-ctype, inttostr, intprops module license

2006-11-14 Thread Yoann Vandoorselaere
On Tue, 2006-11-14 at 12:07 +0100, Bruno Haible wrote: > Yoann Vandoorselaere wrote: > > The following modules are licensed under GPL but used by LGPL modules: > > > > - c-ctype: used by c-strcase, c-strcasestr, linebreak. > > I'm changing the copyright of c-ctype to LGPL: Thanks! > > As new de

have-lib: more tweaks for GNOME libraries

2006-11-14 Thread Bruno Haible
GNOME libraries often have their include files in subdirectories of $prefix/include. The default INC${NAME} flags set by AC_LIB_LINKFLAGS don't help in this case. The invoking macro needs to know the $prefix so it can synthesize the right INC${NAME} flags itself. (If $prefix is /usr or /usr/local,

Re: [bug-gnulib] inline.m4: use compiler, not cpp

2006-11-14 Thread Bruno Haible
Paul Eggert wrote: > whenever you get into trouble, just do "make clean" > and then make with the CFLAGS you prefer. Many hackers probably use the same approach... Since "make CFLAGS=..." does not pass the CFLAGS down to subdirectories, the user of a package with - its main sources in the main d

have-lib: support for libraries with dots in their name

2006-11-14 Thread Bruno Haible
This adds support for libraries with dots in their name (seen frequently in GNOME libraries). 2006-11-12 Bruno Haible <[EMAIL PROTECTED]> * m4/lib-link.m4: Require at least autoconf-2.54. (AC_LIB_LINKFLAGS_BODY) [autoconf < 2.61]: Turn dots into the library name to under

c-ctype, inttostr, intprops module license

2006-11-14 Thread Yoann Vandoorselaere
Hi, The following modules are licensed under GPL but used by LGPL modules: - c-ctype: used by c-strcase, c-strcasestr, linebreak. - inttostr: used by getaddrinfo - intprops: used by stdint-tests, inttostr (which should be LGPL). As new dependencies get introduced to existing GnuLib modules, it

Re: [bug-gnulib] gnulib-tool --with-tests --test

2006-11-14 Thread Bruno Haible
Ralf Wildenhues wrote: > > About the gl_source_base of the tests directory: The idea is that > > the tests directory has its sources separate from the main directory, > > so that when a dependency (providing a .h file, for example) is missing > > from a library module but present in the tests modul

Re: missing dependencies

2006-11-14 Thread Jim Meyering
Ralf Wildenhues <[EMAIL PROTECTED]> wrote: ... > coreutils now still needs one more fix, after Jim's: > some of its own lib files are still not dependency-tracked: > | ls: .deps/fdopendir-glibc.Po: No such file or directory > | ls: .deps/lstat-stub.Po: No such file or directory > | ls: .deps/readli

some warnings in tests/

2006-11-14 Thread Ralf Wildenhues
Hello Simon, OK to apply? This makes tests/ 'gcc -Wall -Werror' proof. Cheers, Ralf 2006-11-13 Ralf Wildenhues <[EMAIL PROTECTED]> * tests/test-gc.c (main): Remove unused variables. * tests/test-read-file.c: Include stdlib.h, for 'free'. Index: tests/test-gc.c ==

Re: missing dependencies

2006-11-14 Thread Ralf Wildenhues
* Bruno Haible wrote on Mon, Nov 13, 2006 at 02:33:31PM CET: > Jim Meyering wrote: > > It sounds like the recent trend to remove uses of AC_LIBSOURCE > > (in favor of listing source file names in each module-file Files: section) > > is the reason for at least some of my missing dependencies. > > T