[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: proposed gnulib-related additions to Autoconf]

From: Paul Eggert
Subject: Re: [Fwd: Re: proposed gnulib-related additions to Autoconf]
Date: Thu, 02 Mar 2006 12:49:26 -0800
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Thanks very much for the review.

Ralf Wildenhues <address@hidden> writes:

> Please add a @cindex entry for Gnulib.
> ...
>> +be shared among free-software packages.  Its components are typically
> I'd write  s|free-|free |  as done elsewhere in the documentation.
> ...
> s|automake/, Gnulib|gnulib/, Gnulib|
> ...
>> +expressions that suitable for use even in the preprocessor.  Do not
>> ...
> s|that|& are|
> ...
> Please  s|translit|m4_&|, two instances.

Thanks, will do.

> The AU_DEFUN of AC_C_LONG_DOUBLE is repeated in lib/autoconf/types.m4.

Thanks, will remove the c.m4 version.

> I fear a bit that external code may rely on $ac_cv_c_long_double.

Good point.  I'll modify AC_C_LONG_DOUBLE to set

>> +m4_define([AC_C_TYPE_RANGE_INTEGER],
> Why is this m4_define'd and not AC_DEFUN'd?

No good reason; I'll fix it.

>> +         #include <stdlib.h>
> Doesn't Autoconf code still put the hash in the first column?

It does, yes.  There's no longer any good reason for this (since
nobody uses K&R any more) but I changed things to put the # at the
start.  We can change the policy after 2.60 comes out.

> Not sure if I like all those white space changes (several instances in
> several files) introducing TABs in comments, and making this patch much
> larger than necessary (and more difficult to review for lined-up
> underlines ;-)

Sorry about that; you can use "diff -b" on the old versus the new
to avoid that.  Admittedly it's annoying; I'll try not to do more.

Will do.

> It'd be nice to  s|$|dnl|  for all the AC_REQUIRE and AC_BEFORE.

But that makes the source harder to read.  I'd rather that we worked
toward an approach that allowed nicer source layout.  In the meantime
I'm not sure it's worth the minor benefit in avoiding empty lines in

reply via email to

[Prev in Thread] Current Thread [Next in Thread]