Re: test modules and license

[EMAIL PROTECTED] (Karl Berry) writes: > Is there a problem with having the LGPL'd files in coreutils? It's longstanding practice to distribute code in GNU applications like coreutils under the GPL only, replacing references to the LGPL with references to the GPL in files taken from LGPLed distri

Re: test modules and license

[EMAIL PROTECTED] (Karl Berry) writes: > the --symlink option, in the coreutils situation, > will copy more files and symlink less files. > > Is there a problem with having the LGPL'd files in coreutils? Does it > make any practical difference? How about adding a --gpl parameter to gnuli

Re: Status of the win32 gettimeofday module

Bruno Haible <[EMAIL PROTECTED]> writes: > Reading through the new code and doing cross-compiles to cygwin and mingw > I found and fixed a few further issues: I started a daily build of gnulib for mingw32 now, there are some initial results on: http://autobuild.josefsson.org/gnulib-mingw32/ Ide

Re: gnulib-tool: optimize --create-testdir

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon recently reported that --create-testdir was running configure > when it was not necessary. This fixes it. Thanks, I'm using it now. /Simon

Re: test modules and license

Why not? If we ensure that every user of the gnulib CVS understands it, If someone comes across a file for whatever reason (eg, casually browsing savannah cvs), and they see a license statement in that file, it is obvious that they will assume that that is the license of the file. When a lice

Re: test modules and license

If we say "look yourself in each individual file", how can the user trust gnulib? I agree that an overall statement of what licenses gnulib uses is desirable, including for the doc files. It's only that I think the documentation should document the licenses, and (must) not *be* the licens

Re: Status of the win32 gettimeofday module

Yoann Vandoorselaere asked: > I'm currently working on a win32 port for libprelude, and we're missing > a gettimeofday module working under win32. > > I've noticed an attempt to implement win32 support to the current module > was discussed previously: > http://thread.gmane.org/gmane.comp.lib.gnuli

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert dixit: > […] gcc -O2 makes no promises without > -fwrapv. gcc -O1 -fwrapv even doesn't work correctly for gcc3, and gcc2 and gcc <3.3(?) don't even have -fwrapv: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477 bye, //mirabile -- "Using Lynx is like wearing a really good pair o

Re: Build failure on AIX 4.3

Jim, That did the trick. The coreutils tarball you provided builds (and tests) without a hitch on the same AIX 4.3 system. Thanks for the fix :) --Daniel On Mon, 2007 Jan 15 16:41:04 +0100, Jim Meyering wrote: > > Thanks for the report and analysis. > Here's a proposed patch for the gnulib

Re: assume

Bruno Haible clisp.org> writes: > > > > 2007-01-16 Eric Blake byu.net> > > > > * modules/fnmatch (Depends-on): Depend on wchar. > > * lib/fnmatch.c (WIDE_CHAR_SUPPORT): Assume . > Looks good to me. (The 'stdint' part will make us notice quickly if there's > still some platform out t

Re: [bug-gnulib] assume

Eric Blake wrote: > OK to apply this patch, which makes several modules depend on the recently > added wchar module? > > 2007-01-16 Eric Blake <[EMAIL PROTECTED]> > > * modules/fnmatch (Depends-on): Depend on wchar. > * lib/fnmatch.c (WIDE_CHAR_SUPPORT): Assume . > * modules/m

assume

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK to apply this patch, which makes several modules depend on the recently added wchar module? 2007-01-16 Eric Blake <[EMAIL PROTECTED]> * modules/fnmatch (Depends-on): Depend on wchar. * lib/fnmatch.c (WIDE_CHAR_SUPPORT): Assume .

Re: no separate javaexec-script module?

Thanks for this patch. I've applied a similar one for C# (in case Bison also wants to generate a C# skeleton). 2007-01-16 Bruno Haible <[EMAIL PROTECTED]> * modules/csharpexec-script: New, created from... * modules/csharpexec: ... this. --- modules/csharpexec 13 Oct 2006 12:40

Status of the win32 gettimeofday module

Hi, I'm currently working on a win32 port for libprelude, and we're missing a gettimeofday module working under win32. I've noticed an attempt to implement win32 support to the current module was discussed previously: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/4155/focus=5770 However, t

Re: [PATCH]: Fix poll module under Win32

Le mardi 16 janvier 2007 à 12:44 +0100, Bruno Haible a écrit : > Yoann Vandoorselaere wrote: > > - gnulib-sys_socket-error.diff: > > Under MinGW, map error code required by the poll module (namely > > ESHUTDOWN, ECONNRESET, ECONNABORTED, ENETRESET, ENOTCONN), plus some > > other useful error code.

Re: no separate javaexec-script module?

Yes. Except that the license statement should be "GPLed build tool" rather than "GPL" (so that it can be used in LGPLed packages). Okay, I was not sure I could make that change myself. But I'm curious about the use-case: You are in a situation where you want to execute some Java at build/com

Re: [PATCH]: Fix poll module under Win32

Yoann Vandoorselaere wrote: Hi, Attached are two small patch fixing poll module compilation under MinGW: - gnulib-poll-depend.diff: Add a dependencies on the sys_select module, fixing inclusion error under MinGW. I committed this part. Paolo

Re: [PATCH]: Fix poll module under Win32

Yoann Vandoorselaere wrote: > - gnulib-poll-depend.diff: > Add a dependencies on the sys_select module, fixing inclusion error > under MinGW. Looks OK. > - gnulib-sys_socket-error.diff: > Under MinGW, map error code required by the poll module (namely > ESHUTDOWN, ECONNRESET, ECONNABORTED, ENETR

Re: no separate javaexec-script module?

Paolo Bonzini wrote: > Does the attached patch to the module description files look correct? Yes. Except that the license statement should be "GPLed build tool" rather than "GPL" (so that it can be used in LGPLed packages). But I'm curious about the use-case: You are in a situation where you want

[PATCH]: Fix poll module under Win32

Hi, Attached are two small patch fixing poll module compilation under MinGW: - gnulib-poll-depend.diff: Add a dependencies on the sys_select module, fixing inclusion error under MinGW. - gnulib-sys_socket-error.diff: Under MinGW, map error code required by the poll module (namely ESHUTDOWN, ECO

Re: xreadlink.c initial buffer size guesstimate

On Sat, Jan 13, 2007 at 05:57:24PM -0700, Eric Blake wrote: > According to Liyang HU on 1/13/2007 4:48 PM: > > If xreadlink() assumed POSIX, it would allocate a fixed buffer of 256 bytes. > Wrong. POSIX guarantees that you will have AT LEAST 256, [...] You are absolutely right. > > I'm not even

Re: Build failure on AIX 4.3

"Daniel Richard G." <[EMAIL PROTECTED]> wrote: > That did the trick. The coreutils tarball you provided builds (and tests) > without a hitch on the same AIX 4.3 system. Thanks for confirming. I've checked it in.

Re: test modules and license

Bruno Haible <[EMAIL PROTECTED]> writes: > Fine with me (although I had a slight preference for putting test modules > under the same license as the source modules). I have the same preference. What about the issue of copying code between test code and the library? Then we'd have to talk to the