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:
> | > > |
> | > > | steve@riemann{tmp}cat configure.in
> | > > | AC_INIT
> | > > |
> | > > | AM_CFLAGS=foo
> | > > | steve@riemann{tmp}autoconf
> | > > | configure.in:3: error: undefined macro: AM_CFLAGS
> | > > | steve@riemann{tmp}
> | 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
