-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Paolo Bonzini on 11/24/2008 10:53 PM: >> I'm going to sit on this patch a few more days before applying, unless I get >> a >> review. > > I think you can push the first. Regarding the second, I have two ideas: > > 1) let's see if we can make the special case of requirements work. > Maybe expanding once with > diversion to -1 using m4_divert_require, and once with normal diversion > since the requirements will have been output already. However that > won't work with AS_REQUIRE.
Trust me, I'd like to get m4_require to play nicely with m4_expand, as well. The problem is the usage pattern: AC_FOO(m4_expand(AC_BAR)) If AC_BAR does and m4_require, even if the m4_expand is able to recognize that, m4_expand cannot do anything about it except push it off to a deferred location, because m4_expand is used inside argument collection for AC_FOO. But that deferred location had better be part of the epilogue of AC_FOO, because the required text still needs to collected in the correct order. I might still be able to come up with something... > Can > you send the non-working AS_ESCAPE patch? I did; http://lists.gnu.org/archive/html/autoconf-patches/2008-11/msg00185.html. It fails a few tests where AC_INCLUDES_DEFAULT is involved, again evidence that getting a m4_require to play nicely with m4_expand is worthwhile, rather than that patch's attempt to add AC_INCLUDES_DEFAULT_QUOTED. > > 2) but do we really need it? AS_ESCAPE is a macro that will usually be > used only by Autoconf mavens... AS_ESCAPE lets you convert what would otherwise be an extra process to cat an unquoted here-doc into an AS_ECHO of a double-quoted string. Fewer forks = faster configure scripts. It's a very powerful idiom, worth documenting. > > BTW, is there a way to kill a diversion without outputting anything? > Maybe you can add that to m4sugar. m4_divert_text([KILL], [m4_undivert(diversion)]) But yes, maybe an m4_divert_discard(diversion) would be nice shorthand for that. Which brings up another weird semantic point of m4: m4_undivert honors the current diversion, even during argument collection. So my current patch for m4_divert_text vs. m4_expand isn't quite right: m4_expand([m4_divert_text([KILL], [m4_undivert(diversion)])]) should kill the text currently in diversion, but with the current state of the patch, it routes it to the current diversion rather than KILL. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkksBLMACgkQ84KuGfSFAYCcpwCfQZu9wkfNd1uTAsAwfR1pyhpx ebIAoMhrIXoNmhm9bySTXiUcPwV0A0xD =QCZg -----END PGP SIGNATURE-----
