So gnulib-tool is a 4500 line shell script which you would
like to re-implement to ease maintenance, with the side benefit
of possibly being a bit faster? If performance was the main
reason it would probably be quicker to hack on bash a bit
to speed it up.
If you really want to re-implement it, th
On Sunday 04 January 2009 17:25:40 Bruno Haible wrote:
> If gnulib-tool was to be rewritten in another programming language than
> shell + sed, what would be the good choices?
>
> The foremost criteria IMO should be the maintainability, i.e. the ability
> for us and for new contributors to gnulib t
If gnulib-tool was to be rewritten in another programming language than
shell + sed, what would be the good choices?
The foremost criteria IMO should be the maintainability, i.e. the ability for
us and for new contributors to gnulib to master this programming language.
To get an estimate of this,
Mike Frysinger wrote:
> the gnulib implementations of POSIX functions are pretty damn complete. for
> most of my uses though, they're *too* complete :).
>
> for example, current gnulib will often enable printf functions on modern
> systems (such as Linux w/glibc 2.9). this is because extended f
Jim Meyering wrote:
> Bruno Haible wrote:
> ...
>>> It looks to me like the change below is equivalent to yours,
>>
>> Ah, I see now what you mean. Fine with me.
...
Hi Bruno,
I've reworked those patches accordingly,
but didn't test on a MacOS X system.
Since your name is on them, I'll wait un
This patch adds a generic check for ld.so in config.libpath. It should detect
all Glibc-based systems (and possibly others) without need to maintain a
hardcoded list.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data;
the gnulib implementations of POSIX functions are pretty damn complete. for
most of my uses though, they're *too* complete :).
for example, current gnulib will often enable printf functions on modern
systems (such as Linux w/glibc 2.9). this is because extended floating point
support breaks f
Jim Meyering asked:
> No big deal, but...
>
> Ok, Bruno?
Yes, thanks.
Bruno
a bunch of modules were labeled as obsolete recently, but no information was
included explaining why. perhaps the toplevel NEWS should be updated, as well
as the "Notice" section of each module pointing people to the place for more
information and/or just telling them why right there ...
as it
No big deal, but...
Ok, Bruno?
>From 24cb49400d1349f29f745e74979b5ce45022288f Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 30 Nov 2008 17:08:33 +0100
Subject: [PATCH] remove duplicate inclusion of
---
tests/test-fprintf-posix.c |1 -
tests/test-printf-posix.c|1 -
test
10 matches
Mail list logo
