[Top][All Lists]

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

Re: Bug #593838: AX_CFLAGS_GCC_OPTION misuses AS_VAR_PUSHDEF variable

From: Paolo Bonzini
Subject: Re: Bug #593838: AX_CFLAGS_GCC_OPTION misuses AS_VAR_PUSHDEF variable
Date: Fri, 01 Oct 2010 18:03:05 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100907 Fedora/3.1.3-1.fc13 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.3

On 10/01/2010 05:11 PM, Eric Blake wrote:
On 10/01/2010 09:07 AM, Paolo Bonzini wrote:
On 10/01/2010 03:57 PM, Eric Blake wrote:

Either way, the name of the indirect variable being assigned is
$prefix_a_b, whether you use pre- or post-2.67. Why is 'a=b' being
passed instead of 'a_b' in the first place? I'd need to see more
context of the real macro usage (rather than this trivial test case) to
see whether the efficiency hit is a corner case of a=b is likely in real
life and thus a performance regression, or just an extreme that is not
worth worrying about.

Given it's about GCC options, I'd guess the real parameter was akin to
-Wformat=2 and it's building something like ax_cv_gcc_option__Wformat_2.

Aha; that makes sense to me; and yes, this seems like something enough
packages would want to do. Not only autoconf-archives (with the AX_
prefix), but also gnulib has a macro for detecting compiler warning

Next question - should AX_CFLAGS_GCC_OPTION be doing
m4_translit([$1],[=],[_]) itself prior to using AS_VAR_PUSH, or should
this be folded directly into AS_VAR_PUSH's use of AS_TR_CPP? It boils
down to whether the fix should be in autoconf for all users (and at the
expense of admittedly unlikely indirections like ${foo=bar}), or in the
few macros like AX_CFLAGS_GCC_OPTION that specifically handle =?

I think the correct answer is "do whatever it has been doing until 2.67". :) And the testsuite should be updated to have the appropriate coverage, and I want a pony.


reply via email to

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