Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> alloca.h: alloca_.h
>> rm -f [EMAIL PROTECTED] $@
>> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
>> chmod a-x [EMAIL PROTECTED]
>> mv [EMAIL PROTECTED] $@
>
> One other thing -- how about if we j
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> alloca.h: alloca_.h
>> rm -f [EMAIL PROTECTED] $@
>> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
>> chmod a-x [EMAIL PROTECTED]
>> mv [EMAIL PROTECTED] $@
>
> Surely you meant a-w, not a-x.
Yes
Jim Meyering <[EMAIL PROTECTED]> writes:
> alloca.h: alloca_.h
> rm -f [EMAIL PROTECTED] $@
> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
> chmod a-x [EMAIL PROTECTED]
> mv [EMAIL PROTECTED] $@
One other thing -- how about if we just remove the 'chmod' entirely?
If the source
Where is the other version?
Well, the canonical one is http://www.gnu.org/licenses.
I don't object, but I don't understand why it would be an improvement.
Because the node names would be different, hence the files are
different, hence they should have different names. Seems to me.
Jim Meyering <[EMAIL PROTECTED]> writes:
> alloca.h: alloca_.h
> rm -f [EMAIL PROTECTED] $@
> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
> chmod a-x [EMAIL PROTECTED]
> mv [EMAIL PROTECTED] $@
Surely you meant a-w, not a-x.
Now that so many lib/*.[ch] files in coreutils are generated,
it is harder for me to know when a file comes from gnulib and
when I can modify it in place. I've always taken the stand that
generated files should be read-only, and this is just another
reason to follow that policy. [ I learned long e
Nice idea. A couple of thoughts that I hope can help improve it.
First, the problem occurs not only with proper names, but with any
text string that is English but not ASCII. English mostly uses plain
ASCII, but there are exceptions. Many of the exceptions are words
like naïve that most people
Eric Blake wrote:
> > $ ptx --version| grep Pinard
> > Écrit par F. Pinard.
>
> This one is a translation bug. coreutils source already has a TRANSLATORS
> note before _("F. Pinard") stating that the translator should use the full
> spelling when ç is available, and since you are showing the
Bruno Haible <[EMAIL PROTECTED]> writes:
> OK to add this module to gnulib?
I like the module. But I think that the background and usage
that you included in your message should be checked in also, so
that it's clear. I would not, for example, immediately think to
update the XGETTEXT_OPTIONS va
Simon Josefsson wrote:
> Please install the patch, if I run into
> any problem later on, I'll report it then.
Done. Let's see how it works out.
Bruno
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
> I got an error message from the 'ar' command while using a lib_LIBADD
> augmentation. 'ar' doesn't like -L options. (You can observe this only
> when not using libtool to build the library.) The fix is to use lib_LDFLAGS
> instead. This is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 9/6/2006 6:38 AM:
> Hi all,
>
>
> $ ptx --version| grep Pinard
> Écrit par F. Pinard.
This one is a translation bug. coreutils source already has a TRANSLATORS
note before _("F. Pinard") stating that the translator
Hi all,
What do
Torbjörn Granlund(coreutils)
François Pinard (coreutils)
Danilo Šegan (gettext)
have in common?
A non-ASCII name. This causes trouble in the --version output. The simple
"solution", unfortunately mutilates the name.
$ du --version| grep Granlund
Éc
Hi Simon,
I got an error message from the 'ar' command while using a lib_LIBADD
augmentation. 'ar' doesn't like -L options. (You can observe this only
when not using libtool to build the library.) The fix is to use lib_LDFLAGS
instead. This is also precisely what's documented in the automake manua
This initializes lib..._LDFLAGS, so that it can be augmented later.
2006-09-05 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_emit_lib_Makefile_am): Initialize also
lib_..._LDFLAGS.
*** gnulib-tool.bak 2006-09-06 01:46:53.0 +0200
--- gnulib-tool 2006-09-06 02
Hi,
I added this module. It's an xalloc-checking wrapper of 'striconv'.
* modules/xstriconv: New file.
* lib/xstriconv.h: New file.
* lib/xstriconv.c: New file.
= modules/xstriconv =
Description:
Character set conve
Hi,
I added this merge between Simon's iconvme module and gettext's iconvstring
module.
Migration path:
iconvme::iconv_string -> str_iconv
iconvme::iconv_alloc -> str_cd_iconv (with reversed arguments)
iconvstring::iconv_string -> xmem_cd_iconv (with modified arguments)
* modules/stric
Davide Angelocola <[EMAIL PROTECTED]> writes:
> On Wednesday 06 September 2006 08:20, Sergey Poznyakoff wrote:
>> In mailutils, we use the function argcv_get:
>>
>> int argcv_get (const char *string, const char *delim, const char *cmnt,
>>int *argc, char ***argv);
>>
>> which break
[EMAIL PROTECTED] (Karl Berry) writes:
> I believe this is a good time to improve things like this.
>
> Well, I see your point, but on the other hand, it doesn't seem good to
> me to have two known-different files named "gpl.texi".
Where is the other version?
> So if we go that route, I sugg
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
>> The interface sounds good to me, let's see the code. ;)
>
> I'm making some changes to iconvme::iconv_string on the way of the merge.
> I've put them on the 'haible-private' branch of lib/iconvme.c. All based
> on code in use in GNU gettext
On Wednesday 06 September 2006 08:20, Sergey Poznyakoff wrote:
> In mailutils, we use the function argcv_get:
>
> int argcv_get (const char *string, const char *delim, const char *cmnt,
>int *argc, char ***argv);
>
> which breaks the `string' according to the delimiters in `delim',
On Wednesday 06 September 2006 06:24, you wrote:
> It is not clear, will this split do something like
> like creating an *argv[] list which has a NULL
> pointer as the last element in the array?
exactly
> Hmmm... is argc guarenteed to be positive? If not,
> what does a negative argc mean? If so, w
22 matches
Mail list logo
