Re: Bug #593838: AX_CFLAGS_GCC_OPTION misuses AS_VAR_PUSHDEF variable

[Eric Blake]

On 09/25/2010 12:22 PM, Ben Pfaff wrote:
> retitle 593838 AX_CFLAGS_GCC_OPTION misuses AS_VAR_PUSHDEF variable
> reassign 593838 autoconf-archive
> thanks
>
> Jerome BENOIT<address@hidden>  initially reported that
> AX_CFLAGS_GCC_OPTION(-std=c99) fails with Autoconf 2.67.  Vincent
> Bernat<address@hidden>  determined that the bug could be fixed
> by replacing a literal shell assignment by AS_VAR_SET.
>
> Just now, I took a closer look.  I was able to reduce the problem
> to the following trivial case:
>
> --8<--------------------------cut here-------------------------->8--
> AC_DEFUN([MY_MACRO],
>    [AS_VAR_PUSHDEF([VAR],[prefix_$1])
>
>     dnl This is the version used by AX_CFLAGS_GCC_OPTION.
>     dnl I believe that it is incorrect.  It does not work on Autoconf>= 2.67.
>     VAR=the_value

You are correct that this will not work if VAR is an indirect variable 
name.  It all depends on whether $1 is determined to be an indirection.

MY_MACRO([blah])

is direct; it expands to AS_VAR_PUSHDEF([VAR],[prefix_blah]), at which 
point VAR is the literal string prefix_blah, and you still have valid 
shell code (by sheer luck, and not because you followed the 
documentation).  But

foo=bar
MY_MACRO([$foo])

is indirect; it expands to AS_VAR_PUSHDEF([VAR],[prefix_$foo]), and you 
MUST use AS_VAR_SET([VAR]) in order to set the shell variable prefix_bar 
(as that is what the indirection results in).  Direct use of VAR as a 
shell-variable name will result in invalid shell code.

> On that basis, I infer that one is not supposed to use the
> M4-NAME literally, and thus I believe that this is a bug in
> AX_CFLAGS_GCC_OPTION.  So, I am reassigning this bug to
> autoconf-archive (with this email).

That is the correct course of action.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org