Re: m4_wrap behavior

[Ralf Wildenhues]

* Paul Eggert wrote on Tue, Jun 13, 2006 at 07:08:24PM CEST:
> My kneejerk suggestion is to implement m4wrap as POSIX requires, but
> to add another primitive (m4parw? :-) that works the way 1.4.4 m4wrap
> does.  We can then ask people who prefer things the old-fashioned way
> to use m4parw.

Yes.  But one question is whether existing usage of m4_wrap (not m4wrap)
breaks when m4wrap (and thus m4_wrap, if Autoconf doesn't take measures)
changes its semantics, and consequently, whether Autoconf should maybe
offer a consistent m4_wrap (and m4_parw?) over the then-inconsistent
(after the change) m4wrap.  In any case, Autoconf should not suggest its
users to use plain M4 primitives.

FWIW, there are only a handful of uses of m4_wrap in Autoconf >= 2.59.
All look like they don't care about the order, but I haven't actually
tested that.  And even then, packages may make use of internals in a way
that the order could affect the output.

The most prominent user of plain m4wrap I've found was GMP, and it seems
to be aware of the different order semantics of GNU m4 vs. BSD m4
(again, untested).

Cheers,
Ralf