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