bug-autoconf
[Top][All Lists]
Advanced

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

Re: autoconf 2.61: AC_DEFINE variable with parenthesis


From: Paul Eggert
Subject: Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Date: Wed, 27 Dec 2006 23:59:29 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

"Steven G. Johnson" <address@hidden> writes:

> why not say that the characters must be in
> [A-Za-z0-9_,()], and must form a valid cpp identifier and (optionally)
> a valid cpp argument list?

That's a reasonable restriction, except....

> (Ellipses are a C99 feature and it would not be a good idea to point
> users to them in a config.h file.)

I don't see why not.  One can easily use Autoconf to require C99, or
to detect whether C99 is in use, and then (in a C99 context) it'd be
reasonable to use ellipses.

> White space in the name is disallowed according to the current
> documentation.

I assume this is talking about the documentation as altered by the
2006-12-15 change that disallowed parentheses in the name as well.  So
the idea is to rewrite that newly added restriction....

> I'm not proposing "going back" to an "old way" of doing things.  This
> is not a regression, just documentation of a reasonable and simple
> feature that autoconf has supported and relied upon internally for 6+
> years.

But there are at least two regressions here.  First, the one reported
by Andrey Simonenko in
<http://lists.gnu.org/archive/html/bug-autoconf/2006-12/msg00026.html>,
where AC_DEFINE([DEF(x)], [somevalue]) does not work in Autoconf 2.61
as it did in Autoconf 2.59.  Second, the one I introduced in
<http://lists.gnu.org/archive/html/bug-autoconf/2006-12/msg00031.html>,
which explicitly generates a warning when you invoke
AC_DEFINE([DEF(x)], [somevalue]).

Any change to the documentation that defines AC_DEFINE to have its
circa-2.59 meaning would need to be accompanied by a change to the
code that fixes these two regressions.  So far we don't yet have a
specific patch proposed to do all these things (documentation + at
least two code changes, I assume).  I can easily generate a patch to
fix the latter regression, but I don't know how the former regression
came about.

> I don't quite understand why you want this documentation to be
> dependent on completely new features (checking of the AC_DEFINE
> variable for invalid characters, or documentation of multiple
> AC_DEFINE statements for the same variable) that apply equally to the
> old AC_DEFINE stuff.

I'm trying to get the documentation fixed so that it's not so vague in
this area -- clearly there are problems, since the behavior isn't well
understood (at least by me).  Since we're in the area, let's fix the
obvious documentation problems in it.  Admittedly this is not
essential, but I'd rather not have to revisit the same issue later.




reply via email to

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