On Sat, 2 Aug 2008, Bruno Haible wrote:
> * gnulib-tool (func_import): When updating or creating a .gitignore
> file, prepend each added line with a slash, and ignore leading slashes
> from the existing lines.
Thanks Bruno. It works for me.
On Wed, Jul 30, 2008 at 10:59 PM, Eric Blake <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Dennis Clarke on 7/30/2008 9:17 AM:
> |> Somehow, the test needs to be made more robust; we either need more m4
> |> magic to determine if -lm is necessary for
Vefa Bicakci <[EMAIL PROTECTED]> wrote:
> As you can guess from the subject line, the date program
Thank you for the bug report!
To summarize, this invocation of date should not fail:
$ LC_MESSAGES=C LC_CTYPE=tr_TR.UTF-8 date -d Fri
date: invalid date `Fri'
...
> + setlocale(LC_ALL, "C")
Hi,
Joel E. Denny wrote:
> Would you consider adding a --anchor-vc-ignore option to gnulib-tool?
> This option would tell gnulib-tool to precede every .gitignore entry it
> creates with "/" so that, as with .cvsignore, the entry would not apply
> recursively to subdirectories.
Oh, I wasn't aw
Le samedi 02 août 2008 à 12:15 +0200, Bruno Haible a écrit :
> Yoann Vandoorselaere wrote:
> > > Can you propose a reasonable compromise?
> >
> > Move the macro code into inline function, use the macro to call the
> > appropriate function. The function return the error, the macro abort()
> > in ca
Yoann Vandoorselaere wrote:
> > Can you propose a reasonable compromise?
>
> Move the macro code into inline function, use the macro to call the
> appropriate function. The function return the error, the macro abort()
> in case an error is returned.
OK, sounds acceptable. What naming convention
Hi,
Reuben Thomas wrote:
> strrstr, which is to strstr as strrchr is to strchr, is a useful and
> moderately widely-used function.
Is it useful? Like strstr, is works on strings of bytes, not characters.
I.e. if it is applied to strings of characters, the result is wrong in
multibyte locales who
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * top/GNUmakefile: Avoid 'else COND', which older GNU make
> versions do not understand.
> OK to apply?
Hi Ralf,
Sure. FYI (to other readers), other than indentation changes,
this just inserts a newline in the "else ifneq..."
line and adds the then-r
* top/GNUmakefile: Avoid 'else COND', which older GNU make
versions do not understand.
---
Hello Jim,
OK to apply?
Thanks,
Ralf
top/GNUmakefile | 26 ++
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/top/GNUmakefile b/top/GNUmakefile
index ea5e72c..8b
On Sun, 27 Jul 2008, Joel E. Denny wrote:
> Maybe the top-level Makefile.am should declare .version to depend on
> configure so they don't get out of sync.
I'm considering pushing the following patch to Bison. I'll wait a little
for comments because this area seems a little controversial.
By
10 matches
Mail list logo
