Re: [gnu-prog-discuss] url's in --help output

>>> + printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT); [...] > However, as far as I know there isn't a gnulib translation domain that > is automatically used for messages in gnulib code when you import it to > a project. So the strings above will end up in every project's *.po > files,

Re: c-strtod threading and documentation problems

On Wed, Jan 21, 2009 at 12:39:50 +0100, Bruno Haible wrote: > Yes. While the strtod specification explains the locale dependency of the > decimal point, it does not do so for the digits; hence it's safe to assume > that the digits understood by strtod are only '0'..'9'. Actually, C99 states 'In ot

Re: [gnu-prog-discuss] url's in --help output

OTOH, Karl's message suggests that it's the job of `--help', not `--version', so it may not be a good idea. I don't see a reason to have it in --version. But if people think it's a good idea to optionally have it there, we could ask rms. It should definitely be in --help.

Re: [gnu-prog-discuss] url's in --help output

However, as far as I know there isn't a gnulib translation domain that There actually is, although I admit I don't know how the messages get integrated into the gnulib-using packages: http://translationproject.org/domain/gnulib.html If this is incorporated into a project as a Gnulib modul

Re: expand-before-require bug

Eric Blake wrote: > > I think you should also deprecate AC_GNU_SOURCE in autoconf. > > It already is deprecated, as of autoconf 2.62 You're right. Sorry, my mistake. Bruno

Re: [gnu-prog-discuss] url's in --help output

2009/1/22 Simon Josefsson : > > I don't follow? The comment is aimed at translators, and translators > will add the 'Report translation bugs ...' line in the particular > gettext translation file. Thus, source code is not modified. Thanks, I understand now. I thought the instruction meant to ad

Re: [gnu-prog-discuss] url's in --help output

Neil Jerram writes: > 2009/1/22 Simon Josefsson : >> Here it is. The module name and source filenames are rather long, but I >> couldn't think of anything better. Untested, beware! > >> +void >> +emit_bug_reporting_address (void) >> +{ >> + /* TRANSLATORS: The placeholder indicates the bug-rep

Re: [gnu-prog-discuss] url's in --help output

2009/1/22 Simon Josefsson : > Here it is. The module name and source filenames are rather long, but I > couldn't think of anything better. Untested, beware! > +void > +emit_bug_reporting_address (void) > +{ > + /* TRANSLATORS: The placeholder indicates the bug-reporting address > + for this

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/22/2009 5:31 AM: > Eric, >> * modules/errno (configure.ac): Require, rather than expand, >> gl_HEADER_ERRNO_H. >> * m4/errno_h.m4 (gl_HEADER_ERRNO_H_BODY): Merge... >> (gl_HEADER_ERRNO_H): ...into this macro, and use AC_

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/22/2009 4:42 AM: > Hi Eric, > > [CCing bug-autoconf. This is a reply to > ] > >> * gnulib-tool (func_dest_tmpfilename, func_create_testdir): Using >>

Re: expand-before-require bug

Eric, I wrote: > - provide a documented way to avoid the warning for a particular macro, > I much prefer to have a macro which can be both invoked and required, > even if it requires one more line of code to write it down, than to have > a macro with restricted use. Here's a concret

Re: expand-before-require bug

Hi Eric, > * modules/errno (configure.ac): Require, rather than expand, > gl_HEADER_ERRNO_H. > * m4/errno_h.m4 (gl_HEADER_ERRNO_H_BODY): Merge... > (gl_HEADER_ERRNO_H): ...into this macro, and use AC_DEFUN_ONCE to > enforce that all clients require it. This change is a step backwards. It makes th

Re: [gnu-prog-discuss] url's in --help output

l...@gnu.org (Ludovic Courtès) writes: > Simon Josefsson writes: > >> l...@gnu.org (Ludovic Courtès) writes: > >>> Is there any reason this cannot be made part of `version-etc'? >> >> No reason. It seems like a better place actually. Jim, how about this >> patch? > > And while we're at it, can'

Re: expand-before-require bug

Hi Eric, [CCing bug-autoconf. This is a reply to ] > * gnulib-tool (func_dest_tmpfilename, func_create_testdir): Using > obsolete AC_GNU_SOURCE causes out-of-order expansion; avoid it, > and rely solely on gl_USE_SYSTEM_EXTENSIO

c-strtod: handling of out-of-memory

Now, when there is an out-of-memory while c_strtod is called, the handling is inconsistent: - If it occurs inside newlocale() or inside strtod_l() or inside strtod(), the function returns 0 with errno set to ENOMEM. - If it occurs inside strdup() of the locale string, the function calls

Re: [gnu-prog-discuss] url's in --help output

Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: >> Is there any reason this cannot be made part of `version-etc'? > > No reason. It seems like a better place actually. Jim, how about this > patch? And while we're at it, can't `version_etc ()' print the bug-reporting informati

Re: [gnu-prog-discuss] url's in --help output

l...@gnu.org (Ludovic Courtès) writes: > Hello, > > Simon Josefsson writes: > >> I suggest a new gnulib module emit-bug-reporting-address. I have the >> following code in GNU Libidn, which is strongly influenced by GNU >> CoreUtils. Removing the 'static' keyword and putting it in a gnulib >> mo

Re: [gnu-prog-discuss] url's in --help output

Hello, Simon Josefsson writes: > I suggest a new gnulib module emit-bug-reporting-address. I have the > following code in GNU Libidn, which is strongly influenced by GNU > CoreUtils. Removing the 'static' keyword and putting it in a gnulib > module would make it easy to re-use the code, and po

Re: [gnu-prog-discuss] url's in --help output

Here it is. The module name and source filenames are rather long, but I couldn't think of anything better. Untested, beware! /Simon >From 52901a4bf1eb6dbbac9aa5a8676e120da3d3c134 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 22 Jan 2009 10:18:33 +0100 Subject: [PATCH] Add new modul

Re: [gnu-prog-discuss] url's in --help output

l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Eric Blake writes: > >> Would it help if autoconf were taught to make the package homepage into an >> automatic C preprocessor macro by providing it as an optional argument of >> AC_INIT, similar to other variables like PACKAGE_NAME, PACKAGE_TARNAM