bug-autoconf
[Top][All Lists]
Advanced

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

Re: another problem after updating autoconf-2.61 to 2.62


From: Eric Blake
Subject: Re: another problem after updating autoconf-2.61 to 2.62
Date: Fri, 6 Jun 2008 14:21:42 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

Hi Ralf,

> > I argue that this is a bug in the user's code; the documentation for 
> > AT_KEYWORDS is unchanged since 2.61:
> 
> In which way does the documentation make it clear that
>   AT_KEYWORDS([m4_if([$1], [dummy], [], [$1 ])dummy])
> 
> is a bug, while
>   AT_SETUP([m4_if([$1], [dummy], [], [$1 ])dummy])
> 
> works?  Sorry, but I really don't get that from the manual.

I see your point.

Suppose we do:
m4_define([macro], [one.h two.h])

In the case of AT_SETUP, which does not mention a space-separated list at all, 
both AT_SETUP(macro) and AT_SETUP([macro]) result in the testsuite having the 
output "one.h two.h" as the test title, because conceptually, we don't care 
whether the argument will undergo further macro expansion, as long as the final 
output is fully expanded.

What about AC_CHECK_HEADERS_ONCE, which is documented as taking a space-
separated list?  AC_CHECK_HEADERS_ONCE is given the literal list "one.h two.h", 
vs. AC_CHECK_HEADERS_ONCE([macro])?  Well, here the code uses m4_foreach_w 
under the hood, which performs one round of macro expansions.  If you want to 
search for a header named "macro", the quoting rule of thumb still applies (use 
AC_CHECK_HEADERS_ONCE([[macro]]) as the space-separated list).

Therefore, you are correct - the manual's semantics for a space-separated list 
(at least, according to m4_foreach_w), is one that undergoes one layer of 
expansion before looking for the spaces.  So I retract my claim that the user 
code is buggy, and instead admit that yesterday's fix is a full-blown 
regression fix and not just a QoI improvement in AT_KEYWORDS.  In other words, 
the user should be able to do AT_KEYWORDS([macro]) for the keywords one.h and 
two.h, vs. AT_KEYWORDS([[macro]]) for the keyword macro (and AT_KEYWORDS
([[[macro]]]) if they want the keyword to be a literal "[macro]").

But I stand by the claim that the user can rewrite their code to expand prior 
to invoking AT_KEYWORDS as a workaround to the broken AT_KEYWORDS in pristine 
2.62.

-- 
Eric Blake






reply via email to

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