Re: recent gnulib changes require coreutils adaptations
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> Comparing the differences in the sh -x output should >> help us get to the bottom of this. > > Yes, thanks, that did the trick. > > It turns out that my personal "ls" defaults to "ls -A" (this is an old > security-related habit of mine), but the coreutils bootstrap procedure > (accidentally or deliberately? I can't easily tell which) relies on > the fact that "ls" does not output file names beginning with ".". The > following patch ports to my personal environment (which I hope you > don't mind supporting). If it were anyone else, I'd simply tell them to use a function or shell alias instead, so that it wouldn't interfere with non-interactive uses. But since it's you, I'll make an exception :-) > The more worrisome aspect here is that the current bootstrap > environment seems to assume that gnulib file names won't start with > ".". Is that a safe assumption in the future? Maybe not. If/when gnulib starts distributing files with such names, we can address it,... assuming bootstrap even exists.
Re: Utility script for gnulib
On 7/15/07, Simon Josefsson <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] writes: > Hello, > > GNU findutils has a shell script that automatically checks out a given > list of gnulib modules from CVS. You might want to include this or > link to it to avoid duplication of this work. > > The script is called "import-gnulib.sh" and its configuration file is > named "import-gnulib.config". They should be easy to find. Gnulib already includes a similar script, called gnulib-tool. Did you notice it, or was there some special need for which you needed your import-gnulib? Gnulib-tool is used in many projects already, and is pretty flexible. It is; indeed, import-gnulib.sh calls gnulib-tool. The import-gnulib.sh program is more like a fairly basic variant of coreutils' bootstrap program. James.
Re: xstrtol.h (was: Re: POTFILES.in updates?)
Eric Blake wrote:
> > The lib/gettext.h file already arranges for this (with the i18n domain name
> > being not just "gnulib", but "findutils-gnulib" or similar).
>
> That won't work in headers. For .c files, they are compiled as part of
> the gnulib library, where the DEFAULT_TEXT_DOMAIN is in effect. But for
> the .h files, such as xstrtol.h, they are compiled as part of the main
> program, where gettext() is no longer a macro to the -domain. It
> looks like we'll have to edit any use of gettext in gnulib headers to
> instead use something from a .c file
There is only one use of gettext() in header files in gnulib, the one in
xstrtol.h, and it needs to be revised anyway: It violates the principle
that the translator must be presented whole sentences. Things like
gettext ("invalid %s `%s'")
where the first %s comes from
STRTOL_FATAL_ERROR (spec, _("block size"), e);
are not translatable to languages (such as German), where the adjective's
flexion depends on the gender of the noun.
The macro should be rewritten to take three localized strings as arguments,
instead of just one.
Bruno
Re: files under build-aux/ are forgotten to be distributed
Eric Blake wrote: > > * gnulib-tool (func_get_automake_snippet): Synthesize also an > > EXTRA_DIST augmentation for files in build-aux/. > > Could we also do that for diff files grabbed from under --local-dir? I found > it annoying that for m4 1.4.10, I had to manually update EXTRA_DIST to pick > up > local/doc/gpl-3.0.texi.diff, only to have to undo it again a week later when > I > deleted the diff file because of the upstream .texi changes. I find this annoying too, with the --local-dir that I maintain in gettext. However, for gnulib-tool the --local-dir is conceptually read-only, i.e. input. It can even be a directory outside the distribution. It would not be a good idea to make it read-write. The cleanest solution is probably to hack some automake 'dist' hook that adds all files of the subdirectory (except those generated by automake itself, like Makefile.in and Makefile, and versioning system directories) to the list of files to be distributed. Bruno
Re: Reliance on
On 7/18/07, Ludovic Courtès <[EMAIL PROTECTED]> wrote: Alternatively, maybe `gnulib-tool --import' should say something like "Make sure `lib/config.h' is available, e.g., by adding `AC_CONFIG_LINKS(bla bla)' to your `configure.ac' file." I vote against adding more such messages. gnulib-tool already produces several times more output than is probably useful. I would vote for moving toward a situation where gnulib-tool optionally just checks if you already did the things it thinks you should do. My rationale is that the big-lost-of-things-to-do works fine for first-time adopters, but for those who routinely run it, there is no sense of incremental change; there's no easy way of noticing that an extra recommendation has appeared. Of course, all this is easier said than done, it's probably quite hard to check that the caller has actually done that stuff. James.
Re: xstrtol.h
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Eric Blake wrote:
>> > The lib/gettext.h file already arranges for this (with the i18n domain name
>> > being not just "gnulib", but "findutils-gnulib" or similar).
>>
>> That won't work in headers. For .c files, they are compiled as part of
>> the gnulib library, where the DEFAULT_TEXT_DOMAIN is in effect. But for
>> the .h files, such as xstrtol.h, they are compiled as part of the main
>> program, where gettext() is no longer a macro to the -domain. It
>> looks like we'll have to edit any use of gettext in gnulib headers to
>> instead use something from a .c file
>
> There is only one use of gettext() in header files in gnulib, the one in
> xstrtol.h, and it needs to be revised anyway: It violates the principle
> that the translator must be presented whole sentences. Things like
>
> gettext ("invalid %s `%s'")
>
> where the first %s comes from
>
> STRTOL_FATAL_ERROR (spec, _("block size"), e);
>
> are not translatable to languages (such as German), where the adjective's
> flexion depends on the gender of the noun.
>
> The macro should be rewritten to take three localized strings as arguments,
> instead of just one.
Hi Bruno,
What do you suggest to use as those strings?
I.e., are you suggesting to convert each of the 5 uses of
STRTOL_FATAL_ERROR in coreutils from e.g.,
STRTOL_FATAL_ERROR (optarg, _("skip argument"), s_err);
to
STRTOL_FATAL_ERROR (optarg,
_("invalid skip argument `%s'"),
_("invalid character following skip argument in `%s'"),
_("skip argument `%s' too large"),
s_err);
That sort of "unfactoring" would be hard for me to swallow.
It doesn't seem justifiable to do that to the code solely
to emit marginally improved diagnostics.
