Re: [PATCH] init.sh: new module, and add minimal tests of its compare function

Bruno Haible wrote: >> * tests/test-init.sh: New file. Hi Bruno, Thanks for the testing and the report. > This test fails on some platforms: > > On Solaris 7, HP-UX 11.00, IRIX 6.5: > > test-init.sh: failed test: err not empty: Can't open -- > FAIL: test-init.sh > > On FreeBSD 6.4: > > test-init.

update-copyright request and patch...

Hello, and Happy New Year :-). I am trying to use gnulib's update-copyright script to update all of GDB's files. It's working quite beautifully, and it's quite fast too. I only have a couple of issues: - C files: In GDB, the style for comments is to avoid the '*' at the start of new files.

new module 'isatty' (was: Re: MS-Windows build of Grep [2/4])

bastien ROUCARIES wrote: > The right fix is : > DWORD st; > /* note use _ version for porting to vc */ > if(!_isattty(fd)) > return 0; > if (!GetConsoleMode(_get_osfhandle(fd), &st)) > return 0; > return 1; > > This is the idea Thanks for the idea. > it is a little bit more complic

Re: git-merge-changelog

Hi Alfred, > The only special "program" in gnulib is git-merge-changelog; though now > that I think about it, it makes more sense to split out > git-merge-changelog into a seperate project. Yes, you're entirely right. The project has been created already: http://savannah.gnu.org/projects/vc-chang

Re: [PATCH] init.sh: new module, and add minimal tests of its compare function

Hi Jim, > * tests/test-init.sh: New file. This test fails on some platforms: On Solaris 7, HP-UX 11.00, IRIX 6.5: test-init.sh: failed test: err not empty: Can't open -- FAIL: test-init.sh On FreeBSD 6.4: test-init.sh: failed test: err not empty: sed: --: No such file or directory PASS: test-

Re: git-merge-changelog in bin_PROGRAMS

What about this? I haven't tried it, but I think it should work. The only special "program" in gnulib is git-merge-changelog; though now that I think about it, it makes more sense to split out git-merge-changelog into a seperate project. 2012-01-03 Alfred M. Szmidt * modules/git-merg

Re: git-merge-changelog in bin_PROGRAMS

> It seems that git-merge-changelog is added to bin_PROGRAMS in the > generated lib/Makefile.am, which causes it to get installed in > exec_prefix/bin (at least in inetutils). Not sure why though It's necessary so that the installation instructions at the top of this file work. "ma

Re: [PATCH 2/3] In commentary, do not use ` to quote.

This patch looks fine to me as well, Paul. Bruno

Re: [PATCH 1/3] Use ', not `, for quoting output.

The patch looks good. No objection from me. Thanks Paul! Bruno

Re: Protection of snippet in config.h

[Bastien, there's no point in removing bug-gnulib from the CC.] bastien ROUCARIES wrote: > > How does the config.h look like that does not work for you? > > See previous answer. I don't see anything dangerous in this file: Why should identifiers like _Noreturn, _GL_UNUSED, _UNUSED_PARAMETER_, et

Re: git-merge-changelog in bin_PROGRAMS

Alfred M. Szmidt wrote: > It seems that git-merge-changelog is added to bin_PROGRAMS in the > generated lib/Makefile.am, which causes it to get installed in > exec_prefix/bin (at least in inetutils). Not sure why though It's necessary so that the installation instructions at the top of this file

Re: Don't use the abbreviation "win" to refer to Windows.

On 01/02/12 12:27, Andy Moreton wrote: > win32 is a widely accepted term It's not accepted as part of the GNU coding standards, and even Microsoft prefers a different name for the API. Even aside from the problematic connotation of "win", "win32" is a dated term, and is heading down the path that

git-merge-changelog in bin_PROGRAMS

It seems that git-merge-changelog is added to bin_PROGRAMS in the generated lib/Makefile.am, which causes it to get installed in exec_prefix/bin (at least in inetutils). Not sure why though; I couldn't find anything that struck me in the ChangeLog. Anyone know?

Re: Protection of snippet in config.h

On 01/02/12 13:05, bastien ROUCARIES wrote: > _Noreturn is safe but I am more affraind by the fact that cpp run in > traditionnal mode and could choke if snippet include C89/C99 > preprocessor directive. I suppose that could be an issue in theory, but in practice it isn't: all of the stuff you m

Re: [PATCH] canonicalize: add support for not resolving symlinks

On 01/02/2012 07:52 PM, Bruno Haible wrote: > Pádraig Brady wrote: >> This is for use in a proposed coreutils `realpath` command. > > The comment in the .c file is now not in sync with the one in the .h file, > and it has a typo. > > Are you ok with this amendment? Yes. thanks Bruno

Re: Protection of snippet in config.h

Le Monday 2 January 2012 19:06:46, Paul Eggert a écrit : > On 01/02/12 07:46, Bastien ROUCARIES wrote: > > Unfortunatly gnulib add some stuff snippet like noreturn in config.h > > that are not really safe from a fortran point of view. > > Could you explain the problem a bit more? I wasn't aware >

Re: Protection of snippet in config.h

Bastien ROUCARIES wrote: > I use regularly gnulib for configuring some fortran program. > > Therefore I include config.h in the top of my fortran file. > Unfortunatly gnulib add some stuff snippet like noreturn in config.h > that are not really safe from a fortran point of view. How does the conf

Re: Don't use the abbreviation "win" to refer to Windows.

On Mon 02 Jan 2012, Paul Eggert wrote: > On 01/02/12 05:53, Andy Moreton wrote: > >> Using the term "win32" does not connote winning or losing > > No doubt it has that connotation only to some people, and not to > others. But we should be communicating to as many people as > possible, including t

Re: [PATCH] canonicalize: add support for not resolving symlinks

Pádraig Brady wrote: > This is for use in a proposed coreutils `realpath` command. The comment in the .c file is now not in sync with the one in the .h file, and it has a typo. Are you ok with this amendment? 2012-01-02 Bruno Haible canonicalize: Tweak 2011-12-29 commit. * l

Re: [PATCH] canonicalize: add support for not resolving symlinks

Eric Blake wrote: > I'd welcome a patch to gnulib to prove me wrong by fixing rpl_stat to be > an object-like instead of function-like macro, all while still allowing > compilation to succeed in all interfaces that take 'struct stat *' as a > parameter, including when using those interfaces via fun

Re: Don't use the abbreviation "win" to refer to Windows.

On 01/02/12 05:53, Andy Moreton wrote: > Microsoft themselves rarely refer to it as the "Windows API" My impression is otherwise. For what it's worth, the Google search '"Windows API' site:microsoft.com' has about 68,900 hits, which is nearly as many hits as "Win32 API" at the same site. And ou

Re: how to do findutils cross-compilation for ARM platform?

> > I met errors as > > arm-linux-gnueabi-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > > -I../../intl -g -MT areadlink-with-size.o -MD -MP -MF $depbase.Tpo -c - o > > areadlink-with-size.o areadlink-with-size.c &&\ > > mv -f $depbase.Tpo $depbase.Po > > In file included f

Re: Protection of snippet in config.h

On 01/02/12 07:46, Bastien ROUCARIES wrote: > Unfortunatly gnulib add some stuff snippet like noreturn in config.h > that are not really safe from a fortran point of view. Could you explain the problem a bit more? I wasn't aware that Fortran code used the identifier "_Noreturn". I suppose you co

lost mails

Hi all, If you are waiting for a reply from me, to a mail sent between 2011 July 9 and 2011 December 24 - whether gnulib related or private -, please resend me that mail and its thread. Unfortunately, I lost the contents of my inbox for the said date range, while migrating from KMail 4.4.10 to KM

Protection of snippet in config.h

hi, I use regularly gnulib for configuring some fortran program. Therefore I include config.h in the top of my fortran file. Unfortunatly gnulib add some stuff snippet like noreturn in config.h that are not really safe from a fortran point of view. Could be possible to protect these snippet if t

[PATCH] gitlog-to-changelog: describe input syntax in --help output

FYI, >From 744b6c6ea8c72b372750ed31f3afed8420b236eb Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 2 Jan 2012 15:53:06 +0100 Subject: [PATCH] gitlog-to-changelog: describe input syntax in --help output * build-aux/gitlog-to-changelog (usage) [SPECIAL SYNTAX]: New section. --- ChangeLog

Re: Don't use the abbreviation "win" to refer to Windows.

On 01/02/2012 02:53 PM, Andy Moreton wrote: > > Using the term "win32" does not connote winning or losing to any but the > most paranoid. Replacing proprietary software with free software is done > by being better: that includes being courteous, and not using derogatory > language. The term "woe32"

Re: Don't use the abbreviation "win" to refer to Windows.

On Mon 02 Jan 2012, Paul Eggert wrote: > Attached is a proposed Gnulib patch to fix some occurrences of > the "win" terminology problem. > > It mostly just substitutes "Woe32" for "Win32", except that for > "Win32 API" it substitutes "Windows API". The Microsoft overview of the API >

[PATCH] gitlog-to-changelog: fix typo in --help: show backslash before email @

The backslash you see here was not printed before this change: $ build-aux/gitlog-to-changelog --help | tail -3 # Change the author to be Paul. Note the escaped "@": s,Jim .*>,Paul Eggert , >From d6e34eccef7fdd4032743eab7c0b1b92c31399e9 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date:

Re: [PATCH] gitlog-to-changelog: Copyright-paperwork-exempt: yes == (tiny change)

Hi Jim, On 31 Dec 2011, at 01:06, Jim Meyering wrote: > I've decided to go ahead and make this change, in spite of the lack of > policy anywhere else. I'll update --help with a note about this separately. > Gary, it's based on the change from you and is still in your name, so > I'll wait for an