Re: branch-1_4 cannot build Autoconf 2.59 any more

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Eric Blake on 3/24/2008 6:08 AM:
| | This isn't sufficient
|
| With the typo corrected, I get no difference on your simple example.
|

I had been wavering for some time, but you have finally given me the
clinching argument.  The next release of M4 will be called 1.6, and not
1.4.11, since this (intentional) change in behavior breaks out-of-the-box
installation of autoconf 2.59.  It also gives more pressure for releasing
autoconf 2.62 - I hope to do so this weekend (with the older GPLv2+ plus
exception licensing used in 2.61, unless a miracle happens and the FSF
lawyers give us the okay on wording for GPLv3+ plus exception this week).

I'm installing this to the M4 NEWS file.  Should I also push a patch to
the autoconf repository branched off of 2.59, to provide a gitweb URL to
the minimal patch to lib/m4sugar/m4sugar.m4 which is required to get 2.59
to build with newer M4?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfnpHgACgkQ84KuGfSFAYCSmwCgsuQPtpkolm78D5oItehZSClV
EY0AoK41WSJYDe3j+NqOVJx1se7c9OS/
=tfsV
-----END PGP SIGNATURE-----

>From 4feea71b985318a35dbdf55b311519112992fa53 Mon Sep 17 00:00:00 2001
From: Eric Blake <address@hidden>
Date: Mon, 24 Mar 2008 06:49:15 -0600
Subject: [PATCH] Mention FIFO m4wrap more prominently in NEWS.

* NEWS: Describe effect on autoconf 2.59 and earlier.
* doc/m4.texinfo (History): The next version will be 1.6, not
1.4.11.
Reported by Ralf Wildenhues.

Signed-off-by: Eric Blake <address@hidden>
---
 ChangeLog      |    6 ++++++
 NEWS           |   16 +++++++++++++---
 doc/m4.texinfo |   20 ++++++++++----------
 3 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d8fc94a..2b9b1bc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2008-03-24  Eric Blake  <address@hidden>
 
+       Mention FIFO m4wrap more prominently in NEWS.
+       * NEWS: Describe effect on autoconf 2.59 and earlier.
+       * doc/m4.texinfo (History): The next version will be 1.6, not
+       1.4.11.
+       Reported by Ralf Wildenhues.
+
        Pull GNUmakefile from gnulib.
        * m4/gnulib-cache.m4: Import gnumakefile module.
        * GNUmakefile: Remove from version control; supplied by gnulib
diff --git a/NEWS b/NEWS
index 53f7282..2e2b33a 100644
--- a/NEWS
+++ b/NEWS
@@ -2,7 +2,7 @@ GNU M4 NEWS - User visible changes.
 Copyright (C) 1992, 1993, 1994, 2004, 2005, 2006, 2007, 2008 Free Software
 Foundation, Inc.
 
-* Noteworthy changes in Version 1.4.11 (????-??-??) [stable]
+* Noteworthy changes in Version 1.6 (????-??-??) [stable]
   Released by ????, based on git version 1.4.10b.x-*
 
 ** Fix regression introduced in 1.4.10b where using `builtin' or `indir'
@@ -10,7 +10,17 @@ Foundation, Inc.
 
 ** Fix the `m4wrap' builtin to accumulate wrapped text in FIFO order, as
    required by POSIX.  The manual mentions a way to restore the LIFO order
-   present in earlier GNU M4 versions.
+   present in earlier GNU M4 versions.  NOTE: this change exposes a bug
+   in Autoconf 2.59 and earlier (which was fixed in Autoconf 2.60).  If
+   you still need to use older autoconf, then add these lines to your
+   project's configure.ac, prior to calling AC_INIT:
+     # As long as this project is not ready to upgrade to autoconf 2.60,
+     # make sure that newer M4 will still use LIFO order:
+     m4_define([m4_wrap],
+       [m4_ifdef([_$0_text],
+         [m4_define([_$0_text], [$1]m4_defn([_$0_text]))],
+         [m4_define([_$0_text], [$1])m4_builtin([m4wrap],
+           [m4_default(m4_defn([_$0_text])m4_undefine([_$0_text]))])])])
 
 ** Enhance the `ifdef', `ifelse', and `shift' builtins, as well as all
    user macros, to transparently handle builtin tokens generated by `defn'.
@@ -29,7 +39,7 @@ Foundation, Inc.
 
 ** Fix regression introduced in 1.4.9b in the `divert' builtin when more
    than 512 kibibytes are saved in diversions on platforms like NetBSD
-   where fopen(name,"a+") seeks to the end of the file.
+   or darwin where fopen(name,"a+") seeks to the end of the file.
 
 ** The output of the `maketemp' and `mkstemp' builtins is now quoted if a
    file was created.  This is a minor security fix, because it was possible
diff --git a/doc/m4.texinfo b/doc/m4.texinfo
index 67f1765..f79e574 100644
--- a/doc/m4.texinfo
+++ b/doc/m4.texinfo
@@ -396,7 +396,7 @@ prepared patches for the release of 1.4.5, 1.4.6, 1.4.7, 
and 1.4.8.
 More bug fixes were incorporated in 2007, with releases 1.4.9 and
 1.4.10.  In 2008, Eric additionally rewrote the scanning engine to
 reduce recursive evaluation from quadratic to linear complexity for
-1.4.11.  The 1.4.x branch remains open for bug fixes.
+M4 1.6.  The 1.x branch remains open for bug fixes.
 
 Meanwhile, development has continued on new features for @code{m4}, such
 as dynamic module loading and additional builtins.  When complete,
@@ -2218,7 +2218,7 @@ defn([l], [r])
 Using @code{defn} to generate special tokens for builtin macros will
 generate a warning in contexts where a macro name is expected.  But in
 contexts that operate on text, the builtin token is just silently
-converted to an empty string.  As of M4 1.4.11, expansion of user macros
+converted to an empty string.  As of M4 1.6, expansion of user macros
 will also preserve builtin tokens.  However, any use of builtin tokens
 outside of the second argument to @code{define} and @code{pushdef} is
 generally not portable, since earlier @acronym{GNU} M4 versions, as well
@@ -2666,7 +2666,7 @@ ifdef(`no_such_macro', `yes', `no', `extra argument')
 @result{}no
 @end example
 
-As of M4 1.4.11, @code{ifdef} transparently handles builtin tokens
+As of M4 1.6, @code{ifdef} transparently handles builtin tokens
 generated by @code{defn} (@pxref{Defn}) that occur in either
 @var{string}, although a warning is issued for invalid macro names.
 
@@ -2782,7 +2782,7 @@ ifelse(`foo', `bar', `3', `gnu', `gnats', `6', `7', `8')
 @result{}7
 @end example
 
-As of M4 1.4.11, @code{ifelse} transparently handles builtin tokens
+As of M4 1.6, @code{ifelse} transparently handles builtin tokens
 generated by @code{defn} (@pxref{Defn}).  Because of this, it is always
 safe to compare two macro definitions, without worrying whether the
 macro might be a builtin.
@@ -4606,7 +4606,7 @@ not if @code{m4exit} is used to exit @code{m4}.
 
 It is safe to call @code{m4wrap} from wrapped text, where all the
 recursively wrapped text is deferred until the current wrapped text is
-exhausted.  As of M4 1.4.11, when @code{m4wrap} is not used recursively,
+exhausted.  As of M4 1.6, when @code{m4wrap} is not used recursively,
 the saved pieces of text are reread in the same order in which they were
 saved (FIFO---first in, first out), as required by @acronym{POSIX}.
 
@@ -6425,7 +6425,7 @@ version of @code{maketemp} is secure.  This means that 
using the same
 template to multiple calls will generate multiple files.  However, we
 recommend that you use the new @code{mkstemp} macro, introduced in
 @acronym{GNU} M4 1.4.8, which is secure even in traditional mode.  Also,
-as of M4 1.4.11, the secure implementation quotes the resulting file
+as of M4 1.6, the secure implementation quotes the resulting file
 name, so that you are guaranteed to know what file was created even if
 the random file name happens to match an existing macro.  Notice that
 this example is careful to use @code{defn} to avoid unintended expansion
@@ -6807,7 +6807,7 @@ changed strings for quotes or comments.  And future 
releases of
 
 @ignore
 @c This example is not worth putting in the manual, but caused core
address@hidden dumps in all versions prior to 1.4.11.
address@hidden dumps in all versions prior to 1.6.
 
 @comment options: -F /dev/null
 @example
@@ -7070,7 +7070,7 @@ of @samp{-} on the command line.
 @item
 @acronym{POSIX} requires @code{m4wrap} (@pxref{M4wrap}) to act in FIFO
 (first-in, first-out) order, and most other implementations obey this.
-However, versions of @acronym{GNU} @code{m4} earlier than 1.4.11 used
+However, versions of @acronym{GNU} @code{m4} earlier than 1.6 used
 LIFO order.  Furthermore, @acronym{POSIX} states that only the first
 argument to @code{m4wrap} is saved for later evaluation, but
 @acronym{GNU} @code{m4} saves and processes all arguments, with output
@@ -7534,14 +7534,14 @@ foreachq(`x', ``1', `2', `3', `4'', `x
 @result{}4
 @end example
 
-Prior to M4 1.4.11, every instance of @samp{$@@} was rescanned as it was
+Prior to M4 1.6, every instance of @samp{$@@} was rescanned as it was
 encountered.  Thus, the @file{foreachq3.m4} alternative used much less
 memory than @file{foreachq2.m4}, and executed as much as 10% faster,
 since each iteration encountered fewer @samp{$@@}.  However, the
 implementation of rescanning every byte in @samp{$@@} was quadratic in
 the number of bytes scanned (for example, making the broken version in
 @file{foreachq.m4} cubic, rather than quadratic, in behavior).  Once the
-underlying M4 implementation was improved in 1.4.11 to reuse results of
+underlying M4 implementation was improved in 1.6 to reuse results of
 previous scans, both styles of @code{foreachq} become linear in the
 number of bytes scanned, and the difference in timing is no longer
 noticeable; in fact, after the change, the @file{foreachq2.m4} version
-- 
1.5.4