Fix typos in recent patches.

* lib/m4sugar/m4sugar.m4: Improve m4_defun comments.
* doc/autoconf.texi (Expanded Before Required): Fix typos.
Reported by Ralf Wildenhues.

Signed-off-by: Eric Blake <ebb9@byu.net>

diff --git a/ChangeLog b/ChangeLog
index 996eca1f111a0aaef00c362d6f725246ff3b49e2..3881591cb7d97c69d37d52d5bad1af0be11a01d7 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2009-01-24  Eric Blake  <ebb9@byu.net>
 
+       Fix typos in recent patches.
+       * lib/m4sugar/m4sugar.m4: Improve m4_defun comments.
+       * doc/autoconf.texi (Expanded Before Required): Fix typos.
+       Reported by Ralf Wildenhues.
+
        Revert change to AC_DIR_HEADER.
        * lib/autoconf/headers.m4 (AC_DIR_HEADER): Explicitly expanding
        AC_HEADER_DIRENT no longer triggers a warning, and helps the user

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index b7e63fc132532ee6ea0fdbfed40c2d24d8df966a..4857eeb519f2e3636a9de463641199beccea6950 100644 (file)
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -22839,7 +22839,7 @@ Older versions of Autoconf silently built files with incorrect ordering
 between dependent macros if an outer macro first expanded, then later
 indirectly required, an inner macro.  Starting with Autoconf 2.64, this
 situation no longer generates out-of-order code, but results in
-duplicate output and a diagnosis of a syntax warning:
+duplicate output and a syntax warning:
 
 @example
 $ @kbd{cat configure.ac}
@@ -22864,10 +22864,11 @@ $ @kbd{autoconf}
 @result{}configure.ac:11: the top level
 @end example
 
+@noindent
 To avoid this warning, decide what purpose the macro in question serves.
 If it only needs to be expanded once (for example, if it provides
 initialization text used by later macros), then the fix is to change all
-instance of direct calls to instead go through @code{AC_REQUIRE}
+instances of direct calls to instead go through @code{AC_REQUIRE}
 (@pxref{Prerequisite Macros}).  If, instead, the macro is parameterized
 by arguments or by the current definition of other macros in the m4
 environment, then the macro should always be directly expanded instead

diff --git a/lib/m4sugar/m4sugar.m4 b/lib/m4sugar/m4sugar.m4
index 372298f30b15d76209070ab51bad56a09c9a00d8..df051a65153a5069174f58a7221c2b0f548dd8c9 100644 (file)
--- a/lib/m4sugar/m4sugar.m4
+++ b/lib/m4sugar/m4sugar.m4
@@ -1455,7 +1455,7 @@ m4_define([m4_undivert],
 # 1. Implementation of m4_require
 # ===============================
 #
-# Of course m4_defun AC_PROVIDE's the macro, so that a macro which has
+# Of course m4_defun calls m4_provide, so that a macro which has
 # been expanded is not expanded again when m4_require'd, but the
 # difficult part is the proper expansion of macros when they are
 # m4_require'd.
@@ -1476,8 +1476,8 @@ m4_define([m4_undivert],
 # undivert GROW.  To understand why we need several diversions,
 # consider the following example:
 #
-# | m4_defun([TEST1], [Test...REQUIRE([TEST2])1])
-# | m4_defun([TEST2], [Test...REQUIRE([TEST3])2])
+# | m4_defun([TEST1], [Test...m4_require([TEST2])1])
+# | m4_defun([TEST2], [Test...m4_require([TEST3])2])
 # | m4_defun([TEST3], [Test...3])
 #
 # Because m4_require is not required to be first in the outer macros, we
@@ -1509,10 +1509,10 @@ m4_define([m4_undivert],
 # very surprising results in some situations.  Let's consider the
 # following example to explain the bug:
 #
-# | m4_defun([TEST1],  [REQUIRE([TEST2a])REQUIRE([TEST2b])])
+# | m4_defun([TEST1],  [m4_require([TEST2a])m4_require([TEST2b])])
 # | m4_defun([TEST2a], [])
-# | m4_defun([TEST2b], [REQUIRE([TEST3])])
-# | m4_defun([TEST3],  [REQUIRE([TEST2a])])
+# | m4_defun([TEST2b], [m4_require([TEST3])])
+# | m4_defun([TEST3],  [m4_require([TEST2a])])
 # |
 # | AC_INIT
 # | TEST1
@@ -1547,7 +1547,7 @@ m4_define([m4_undivert],
 # Starting from 2.50, we use an implementation provided by Axel Thimm.
 # The idea is simple: the order in which macros are emitted must be the
 # same as the one in which macros are expanded.  (The bug above can
-# indeed be described as: a macro has been AC_PROVIDE'd before its
+# indeed be described as: a macro has been m4_provide'd before its
 # dependent, but it is emitted after: the lack of correlation between
 # emission and expansion order is guilty).
 #
@@ -1706,8 +1706,8 @@ m4_define([m4_undivert],
 # following example to explain the bug:
 #
 # | m4_defun([TEST1], [1])
-# | m4_defun([TEST2], [2[]REQUIRE([TEST1])])
-# | m4_defun([TEST3], [3 TEST1 REQUIRE([TEST2])])
+# | m4_defun([TEST2], [2[]m4_require([TEST1])])
+# | m4_defun([TEST3], [3 TEST1 m4_require([TEST2])])
 # | TEST3
 #
 # After the prologue of TEST3, we are collecting text in GROW with the
@@ -1730,7 +1730,7 @@ m4_define([m4_undivert],
 # macro.  In other words, we must be careful not to warn on:
 #
 # | m4_defun([TEST4], [4])
-# | m4_defun([TEST5], [TEST4 REQUIRE([TEST5])])
+# | m4_defun([TEST5], [TEST4 m4_require([TEST4])])
 #
 # So, to detect whether a require was direct or indirect, m4_provide
 # stores the diversion number at which a macro was provided.  A