Bruno Haible <[EMAIL PROTECTED]> wrote:
> Karl Berry wrote:
>> A wild thought: what if gnulib-tool saved its output during a run, and
>> then presented a *diff* of the new output and the old output? I at
>> least would find that considerably more readable.
>>
>> (Along with a mention of the file w
Karl Berry wrote:
> A wild thought: what if gnulib-tool saved its output during a run, and
> then presented a *diff* of the new output and the old output? I at
> least would find that considerably more readable.
>
> (Along with a mention of the file where the full output can be found, of
> course
Currently, gnulib-tool emits so much output that
a few new diagnostics may easily go by unnoticed.
Indeed.
A wild thought: what if gnulib-tool saved its output during a run, and
then presented a *diff* of the new output and the old output? I at
least would find that considerably more rea
[EMAIL PROTECTED] (Karl Berry) writes:
> Haven't we implicitly been assuming/providing malloc-gnu since day 1?
> Do we really need to force all gnulib users ('cause pretty much everyone
> needs malloc, after all) to educate themselves about the issue and make
> a choice? Can we just keep malloc a
On Mon, 3 Sep 2007, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Adding gnulib: this thread started at
http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/5717]
thanks for the link and for pointing out the existence of
AC_USE_SYSTEM_EXTENSIONS. I think this is the
[EMAIL PROTECTED] (Karl Berry) writes:
> > I guess the module rename would make it obvious to anyone using the old
> > 'malloc' module that they now need to choose which semantics they want,
> > the simpler 'malloc-gnu' or the POSIX-compliant 'malloc-posix'.
>
> Haven't we implicitly b
