The m4sugar documentation assumes that m4_wrap behaves in a LIFO manner, since that is the behavior of GNU m4 1.4.x's m4wrap. For example, the docs give this example of how not to use m4_wrap, because the two wrapped outputs get concatenated and rescanned: m4_define([foo], [Foo]) m4_define([bar], [Bar]) m4_define([foobar], [FOOBAR]) m4_wrap([bar]) m4_wrap([foo]) @result{}FOOBAR But POSIX requires m4wrap to behave in a FIFO manner, and with POSIX, the above example would output barfoo rather than FOOBAR. I plan to fix the bug in m4 2.0. The question now is whether m4 2.0 should conditionalize LIFO vs. FIFO based on POSIXLY_CORRECT (because existing uses of GNU m4 depend on LIFO), or whether this corner case of m4sugar is not in heavy use, and the fix can be made across the board. Then, in m4sugar, we should just document either that 1) m4_wrap has indeterminate ordering, or 2) m4_wrap will always be LIFO or FIFO, regardless of the underlying m4wrap behavior. As an idea of how to force m4_wrap ordering, this shows how to give m4 1.4.4 FIFO ordering: changequote([,])dnl define([m4wrap_],[0])define([_m4wrap], defn([m4wrap]))dnl define([m4wrap], [ifdef([m4wrap]m4wrap_, [define([m4wrap]m4wrap_, defn([m4wrap]m4wrap_)[$1])], [_m4wrap([define([m4wrap_], incr(m4wrap_))m4wrap]m4wrap_)dnl define([m4wrap]m4wrap_, [$1])])])dnl -- Eric Blake _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf