bug-autoconf
[Top][All Lists]
Advanced

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

Re: AC_SUBST is temperamental in expanding its first argument.


From: Eric Blake
Subject: Re: AC_SUBST is temperamental in expanding its first argument.
Date: Wed, 15 Aug 2012 21:57:56 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

On 08/15/2012 08:50 PM, Nick Bowler wrote:
> Hi folks,
> 
> I noticed today (using Autoconf 2.69, although the problem is still
> present in Git) that when the first argument of AC_SUBST contains
> macro names, the behaviour is very odd.

Thanks for the detailed analysis and patch.

> The Autoconf manual does not say anything about the (non-)expansion of
> the first argument to AC_SUBST.  However, if we look at the definition
> of AC_SUBST in autoconf/lib/autoconf/general.m4, the reason for the
> problem seems clear.  The full definition is reproduced here:
> 
>   m4_define([AC_SUBST],
>   [AS_IDENTIFIER_IF([$1], [],
>     [m4_fatal([$0: `$1' is not a valid shell variable name])])]dnl
>   [AC_SUBST_TRACE([$1])]dnl
>   [m4_pattern_allow([^$1$])]dnl

m4_pattern_allow definitely uses the literal value, rather than going
through further expansion, so you are definitely correct that nothing
else in this macro expands $1.  Whether it should or not is a question
for usability, and, since you correctly pointed out that this is not
documented, we can make the change in either direction without affecting
documented behavior.  So one last litmus test is how the macro is
usually used; even within autoconf itself, we have uses like:

lib/autoconf/c.m4:  AC_SUBST([OPENMP_]_AC_LANG_PREFIX[FLAGS])

where the caller explicitly pre-expanded _AC_LANG_PREFIX rather than
relying on subsequent re-expansion.  Sounds like your analysis is correct.

> Therefore, I believe the correct fix is
> to add additional quoting to this argument, as in:
> 
>   [m4_ifvaln([$2], [[$1]=$2])[]]dnl

I've turned this into a formal patch, and updated THANKS to list your
latest email address.  It would also be nice if you could provide a
one-line patch to the documentation and/or a testsuite, to document that
this behavior is intentional (if not, I'll try to write a followup patch
for that).  Thanks again!

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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