|
From: | Eric Blake |
Subject: | Re: Bug #593838: AX_CFLAGS_GCC_OPTION misuses AS_VAR_PUSHDEF variable |
Date: | Fri, 01 Oct 2010 09:11:57 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.4 |
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 options.
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 =?
-- Eric Blake address@hidden +1-801-349-2682 Libvirt virtualization library http://libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |