bootstrap tweak

Pádraig noticed a Debian Etch system with git-1.4.4, which doesn't support git's --depth=N option, and bootstrap failed there. Now, it uses --depth only if "git clone --help" mentions it. [I nearly removed the optimization altogether, but since it halves the download size from 15M, I made it sligh

improvements to announce-gen user messages

Hi Jim. While attempting to use announce-gen for the first time I discovered and fixed a couple of minor flaws in its user interface. OK to push this to gnulib? commit f70e255e4db6200d6352ba794deb8d4f110461d5 Author: Ben Pfaff <[EMAIL PROTECTED]> Date: Thu Oct 9 22:09:45 2008 -0700 Improv

new module 'ioctl'

This defines a module for the 'ioctl' function, and moves its declaration from to . Hopefully this is the last patch in this series of winsock-related restructuring. 2008-10-09 Bruno Haible <[EMAIL PROTECTED]> New module 'ioctl'. * modules/ioctl: New file. * lib/sys_so

new module sys_ioctl

This adds a module for the header file. 2008-10-09 Bruno Haible <[EMAIL PROTECTED]> New module 'sys_ioctl'. * lib/sys_ioctl.in.h: New file. * m4/sys_ioctl_h.m4: New file. * modules/sys_ioctl: New file. * doc/glibc-headers/sys_ioctl.texi: Mention the new

winsock: fix ioctl prototype

According to POSIX the ioctl() prototype takes 'int' as second argument and then varargs. I'm fixing it like this: 2008-10-09 Bruno Haible <[EMAIL PROTECTED]> * lib/sys_socket.in.h (ioctl): Make signature POSIX compliant. *

Re: [PATCH] use gnulib modules close (new) and open to hook into open/close

Oops, there was a missing link here: When the 'close' module and the 'sys_socket' module are present, then on a mingw system, close() must be replaced - regardless of whether fchdir has requested a replacement for close() or not. This should do it. 2008-10-09 Bruno Haible <[EMAIL PROTECTED]>

Re: [PATCH] use gnulib modules close (new) and open to hook into open/close

And finally: part6, the documentation update. 2008-10-09 Bruno Haible <[EMAIL PROTECTED]> * doc/posix-functions/close.texi: Mention module 'close' instead of module 'sys_socket'. --- doc/posix-functions/close.texi.orig 2008-10-10 02:34:03.0 +0200 +++ doc/posix-functions

status

Where should ioctl() be declared? Certainly not in . Most platforms have it in . Only AIX and Solaris declare it in instead. POSIX specifies it should be declared , but many platforms don't have (and who needs STREAMS anyway?). The de-facto standard is apparently . The ioctl() declaration is

Re: [PATCH] use gnulib modules close (new) and open to hook into open/close

And this is part 5. 2008-10-09 Paolo Bonzini <[EMAIL PROTECTED]> Bruno Haible <[EMAIL PROTECTED]> Combine the two replacements of 'close'. * lib/sys_socket.in.h (close): Define to a reminder to include . (_gl_close_fd_maybe_socket): New declaration.

Re: [PATCH] use gnulib modules close (new) and open to hook into open/close

Part 4 committed like this: 2008-10-09 Paolo Bonzini <[EMAIL PROTECTED]> Bruno Haible <[EMAIL PROTECTED]> New module 'close'. * modules/close: New file. * lib/unistd.in.h (close): Move declaration out of the FCHDIR_REPLACEMENT scope. (_gl_unr

Re: [PATCH] use gnulib modules close (new) and open to hook into open/close

Part 3 committed like this: 2008-10-09 Paolo Bonzini <[EMAIL PROTECTED]> Bruno Haible <[EMAIL PROTECTED]> * lib/fcntl.in.h (open): Simplify conditionals. (_gl_register_fd): New declaration. * lib/fchdir.c (rpl_open): Remove function. * lib/open.c: Wh

Re: bootstrap is broken

> Yes, that's true. But on the other hand, otherwise there would no > explanation for bootstrap's attempt to checkout gnulib itself, no? :-) > > [...] > > bootstrap is meant for people who checked out your project from VCS, so > that they do not need to know about gnulib at all. You do not need t

Re: bootstrap is broken

> + Would it not result in unnecessary commits to the SCM to keep it > synchronized with Gnulib's version? Yes, that's true. But on the other hand, otherwise there would no explanation for bootstrap's attempt to checkout gnulib itself, no? :-) > + A user who wants to fiddle with the release tar

Re: bootstrap is broken

> I don't think this is how bootstrap is meant to be used. You should > distribute it together with your application, and do "./bootstrap > --skip-po --gnulib-srcdir=/devel/gnulib/git/gnulib". Just as the other files pulled in from Gnulib were not part of the source tree, bootstrap was also being

Re: GNUmakefile: git-version-gen, maintainer-check, install

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/9/2008 2:39 AM: > Did you consider using "_version" as the new target name? > With that, GNUmakefile impinges less on the name space of all > subsidiary Makefiles. Sure, that looks like a good improvement. - -- Don't w

Re: [PATCH] use gnulib modules close (new) and open to hook into open/close

Committing this as part 2: 2008-10-09 Paolo Bonzini <[EMAIL PROTECTED]> Bruno Haible <[EMAIL PROTECTED]> * lib/fchdir.c (_gl_unregister_fd): New functions, extracted from rpl_close. (_gl_register_fd): New function, extracted from rpl_open. (rpl_close

Re: [PATCH] use gnulib modules close (new) and open to hook into open/close

Hello Paolo, > > - Declare all functions defined in one .c file and used in another .c file > > in a .h file. This is a basic principle, which > > 1. avoids passing too few or too many arguments to a function after > > a couple of refactorings, > > Yes, I wasn't sure about ho

Re: Winsock wrappers

Paolo Bonzini <[EMAIL PROTECTED]> writes: >>> Maybe gnutls could provide adaptors from read/write to the signature >>> needed for gnulib's transport functions? That would be good enough to >>> avoid duplication in client applications. >> >> I think this was what I meant above, but I'm not sure I

Re: Winsock wrappers

>> Maybe gnutls could provide adaptors from read/write to the signature >> needed for gnulib's transport functions? That would be good enough to >> avoid duplication in client applications. > > I think this was what I meant above, but I'm not sure I understand you. > What I see gnutls defining w

Re: Winsock wrappers

Paolo Bonzini <[EMAIL PROTECTED]> writes: >> Will such applications break if GnuTLS would use winsock wrappers >> send/recv from gnulib instead of the system's? I suspect it will, but >> confirming that would be useful. > > Yes. Thanks. >>> You have to make a choice, and this in turn determines

Re: GNUmakefile: git-version-gen, maintainer-check, install

Eric Blake <[EMAIL PROTECTED]> wrote: ... > + GNUmakefile: add 'make version' target > + * top/GNUmakefile (_curr-ver): Split version update rules... > + (version): ...into a target. Hi Eric, That looks like a fine change. Did you consider using "_version" as the new target name? With

Re: Winsock wrappers

> Will such applications break if GnuTLS would use winsock wrappers > send/recv from gnulib instead of the system's? I suspect it will, but > confirming that would be useful. Yes. > Is there any way for gnulib to detect that a fd was created by gnulib's > winsock wrappers or the native systems?

Re: bootstrap is broken

Debarshi Ray wrote: >>> This particular change due to 29dd8b5548ce047ce51ff9a73d6c4b50c9886771 >>> has broken bootstrap for the particular use case where it is invoked >>> using an absolute path (eg., >>> /devel/gnulib/git/gnulib/build-aux/bootstrap --skip-po >>> --gnulib-srcdir=/devel/gnulib/git/g

Re: Winsock wrappers

Paolo Bonzini <[EMAIL PROTECTED]> writes: >> However, is it possible for me to ever use the send/recv replacements in >> gnulib? GnuTLS doesn't open the socket, the application does, so I'm >> wondering whether the FD_TO_SOCKET/SOCKET_TO_FD approach works on >> something that wasn't opened by the

Re: Winsock wrappers

> However, is it possible for me to ever use the send/recv replacements in > gnulib? GnuTLS doesn't open the socket, the application does, so I'm > wondering whether the FD_TO_SOCKET/SOCKET_TO_FD approach works on > something that wasn't opened by the gnulib socket function? The > application no

Re: [PATCH] use gnulib modules close (new) and open to hook into open/close

> While I agree that code that uses accept() or socket() is also likely to > use close(), this is only a heuristic, and it can err on both sides: > - You can imagine code (in a library) that returns file descriptors to > the caller. The library code may use socket() but not need close(). >