Re: Release candidate

[Steve M. Robbins]

On Mon, May 14, 2001 at 05:50:50PM +0200, Akim Demaille wrote:
> 
> | On Mon, May 14, 2001 at 04:57:57PM +0200, Peter Eisentraut wrote:
> | > Akim Demaille writes:
> | > 
> | > > | There is still the problem that autoconf mixes up variable assignments
> | > > | and macros.  This is up-to-the-minute CVS autoconf:
> | > > |
> | > > |         address@hidden configure.in
> | > > |         AC_INIT
> | > > |
> | > > |         AM_CFLAGS=foo
> | > > |         address@hidden
> | > > |         configure.in:3: error: undefined macro: AM_CFLAGS
> | > > |         address@hidden

> | Maybe I don't see what others see.  To me,
> | 
> |         FOO=bar
> | 
> | looks like a shell variable assignment.  I don't understand why
> | autoconf (apparently) treats this as a macro invocation.
> 
> Because autoconf does not parse sh code, it has no idea it is an
> assignment.
> 
> And anyway it is a _feature_: nothing prevent AM_CFLAGS from being a
> macro expanding into a valid lvalue.  

OOK!  I suppose it could be a macro that expands to an lvalue.  That
never occurred to me.  

> And in this case you want to know it has not be expanded.

Yes.  

On the other hand, if you really meant to assign a variable,
and mistakenly chose a macro name

        AC_CHECK_FUNC=no

then autoconf will run, but you'll get a bogus configure script.

In *this* case, you'd prefer the opposite behaviour.  You'd
rather autoconf warned you if you chose a variable name that
*is* defined as a macro!

Now, granted you can't accomodate both situations.  You can't
both warn if the variable name IS a defined macro and if it is
NOT a defined macro.  I guess if you have to pick one behaviour,
you'd pick the most common case and disallow the other.

Is it common to use a macro that expands to an lvalue?

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants