Re: mingw conflict between mkdtemp and sys_stat

2006-10-27 Thread Paul Eggert
Eric Blake <[EMAIL PROTECTED]> writes: > Also, is it worth changing other modules that depend on stat-macros to > instead depend on sys_stat, and delete the #include "stat-macros.h" line > from their implementation? Sure, but more generally I think it's better to move the stuff into lib/stat_.h,

Re: signed.m4 never again (was: Re: signed.m4 again)

2006-10-27 Thread Bruno Haible
Ralf Wildenhues wrote: > Yes, thank you. OK to apply, Bruno? > > * m4/signed.m4 (bh_C_SIGNED): Avoid uninitialized variable > warning. signed.m4 can go entirely, since gnulib assumes ANSI C for several years already. It is removed from GNU gettext. I'm removing it also from the 'vasn

Re: mingw conflict between mkdtemp and sys_stat

2006-10-27 Thread Eric Blake
Eric Blake byu.net> writes: > The second half, fixing mkdtemp to use the new tempname module and the > existing sys_stat module, so that mkdtemp and mkstemp can coexist on > mingw, still needs Bruno's approval; I'll post that patch later in light > of this commit. And I need mkdtemp fixed before

Re: [bug-gnulib] hello pretest 2.1.94

2006-10-27 Thread Bruno Haible
Hello Karl, > I put another hello pretest at > ftp://alpha.gnu.org/gnu/hello/hello-2.1.94.tar.bz2 (and .gz). It uses automake-1.10 and gettext-0.15, which is a bad combination. ("make install" fails on platforms which don't have a good 'mkdir' program.) The fix should be to use "gettextize" from

update to gettext-0.16

2006-10-27 Thread Bruno Haible
Hi, I'm upgrading the gettext module to gettext-0.16. 2006-10-27 Bruno Haible <[EMAIL PROTECTED]> Update to GNU gettext 0.16. * modules/gettext (Files): Add m4/intl.m4, m4/intldir.m4. Remove m4/inttypes-h.m4, m4/signed.m4. * m4/gettext.m4: Update to GNU gettext

Re: mingw conflict between mkdtemp and sys_stat

2006-10-27 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 10/17/2006 10:03 PM: > Eric Blake <[EMAIL PROTECTED]> writes: > >> It just looks nicer if we provide gnulib >> modules with exported APIs that do not lie in the reserved namespace. > > Sure, but can't you do something like