[PATCH] warnings: fix compilation with old autoconf

[Eric Blake]

Autoconf older than 2.63b (such as what ships on CentOS 6) had
a bug that any AC_DEFUN'd macro name that includes shell meta-
characters causes failure due to missing shell quoting during
aclocal's use of autom4te. We can work around the problem by
using m4_defun instead (same semantics in autom4te, but no
longer traced by aclocal, so no longer tickles the shell
quoting bug).

warnings: fix compilation with old autoconf
* m4/warnings.m4 (gl_UNKNOWN_WARNINGS_ARE_ERRORS(C))
(gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)): Use m4_defun rather than
AC_DEFUN.
* m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC(C))
(gl_MANYWARN_ALL_GCC(C++)): Likewise.

Reported-by: Erik Skultety <***@redhat.com>
Signed-off-by: Eric Blake <***@redhat.com>
---

The fix turned out to be simpler than I had been fearing.

ChangeLog | 9 +++++++++
m4/manywarnings.m4 | 8 +++++---
m4/warnings.m4 | 8 +++++---
3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 05213d62f..e241c9dc1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
[phone] Eric Blake <***@redhat.com>
+
+ warnings: fix compilation with old autoconf
+ * m4/warnings.m4 (gl_UNKNOWN_WARNINGS_ARE_ERRORS(C))
+ (gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)): Use m4_defun rather than
+ AC_DEFUN.
+ * m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC(C))
+ (gl_MANYWARN_ALL_GCC(C++)): Likewise.
+
2017-08-24 Bruno Haible <***@clisp.org>

glob: Fix compilation error on NetBSD 7.0 and OpenBSD 6.0.
diff --git a/m4/manywarnings.m4 b/m4/manywarnings.m4
index a3d255a94..eb8932551 100644
--- a/m4/manywarnings.m4
+++ b/m4/manywarnings.m4
@@ -1,4 +1,4 @@
-# manywarnings.m4 serial 11
+# manywarnings.m4 serial 12
dnl Copyright (C) 2008-2017 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -39,7 +39,8 @@ AC_DEFUN([gl_MANYWARN_ALL_GCC],
[_AC_LANG_DISPATCH([$0], _AC_LANG, $@)])

# Specialization for _AC_LANG = C.
-AC_DEFUN([gl_MANYWARN_ALL_GCC(C)],
+# Use of m4_defun rather than AC_DEFUN works around a bug in autoconf < 2.63b.
+m4_defun([gl_MANYWARN_ALL_GCC(C)],
[
AC_LANG_PUSH([C])

@@ -316,7 +317,8 @@ AC_DEFUN([gl_MANYWARN_ALL_GCC(C)],
])

# Specialization for _AC_LANG = C++.
-AC_DEFUN([gl_MANYWARN_ALL_GCC(C++)],
+# Use of m4_defun rather than AC_DEFUN works around a bug in autoconf < 2.63b.
+m4_defun([gl_MANYWARN_ALL_GCC(C++)],
[
gl_MANYWARN_ALL_GCC_CXX_IMPL([$1])
])
diff --git a/m4/warnings.m4 b/m4/warnings.m4
index aa2735b77..870472b62 100644
--- a/m4/warnings.m4
+++ b/m4/warnings.m4
@@ -1,4 +1,4 @@
-# warnings.m4 serial 12
+# warnings.m4 serial 13
dnl Copyright (C) 2008-2017 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -59,7 +59,8 @@ AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS],
[_AC_LANG_DISPATCH([$0], _AC_LANG, $@)])

# Specialization for _AC_LANG = C. This macro can be AC_REQUIREd.
-AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],
+# Use of m4_defun rather than AC_DEFUN works around a bug in autoconf < 2.63b.
+m4_defun([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],
[
AC_LANG_PUSH([C])
gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL
@@ -67,7 +68,8 @@ AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],
])

# Specialization for _AC_LANG = C++. This macro can be AC_REQUIREd.
-AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)],
+# Use of m4_defun rather than AC_DEFUN works around a bug in autoconf < 2.63b.
+m4_defun([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)],
[
AC_LANG_PUSH([C++])
gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL

[Bruno Haible]

Hi Eric,

Post by Eric Blake
@@ -59,7 +59,8 @@ AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS],
# Specialization for _AC_LANG = C. This macro can be AC_REQUIREd.
-AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],
+# Use of m4_defun rather than AC_DEFUN works around a bug in autoconf < 2.63b.
+m4_defun([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],
[
AC_LANG_PUSH([C])
gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL
@@ -67,7 +68,8 @@ AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],
])
# Specialization for _AC_LANG = C++. This macro can be AC_REQUIREd.
-AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)],
+# Use of m4_defun rather than AC_DEFUN works around a bug in autoconf < 2.63b.
+m4_defun([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)],
[
AC_LANG_PUSH([C++])
gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL

Is m4_defun sufficient for AC_REQUIRE to work? The comments state that it is
essential that these macros can be AC_REQUIREd. This is needed for
gl_WARN_ADD (warnings.m4 line 94).

Bruno

[Eric Blake]

Post by Bruno Haible

Post by Eric Blake
# Specialization for _AC_LANG = C++. This macro can be AC_REQUIREd.
-AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)],
+# Use of m4_defun rather than AC_DEFUN works around a bug in autoconf < 2.63b.
+m4_defun([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)],
[
AC_LANG_PUSH([C++])
gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL

Is m4_defun sufficient for AC_REQUIRE to work? The comments state that it is
essential that these macros can be AC_REQUIREd. This is needed for
gl_WARN_ADD (warnings.m4 line 94).

Yes. Implementation-wise, autoconf has:

m4_copy([m4_defun], [AC_DEFUN])

that is, AC_DEFUN is defined as a copy of the body of m4_defun,
expanding to the same text. Both AC_REQUIRE and m4_require are equally
happy to pull in a macro, regardless of whether it defined via AC_DEFUN
or m4_defun, making them interchangeable for what output is produced.

Therefore, the difference between the two macros is based solely on the
fact that tracing depends on which macro name is invoked. Generally,
you want to avoid the m4_ macros in favor of the AC_ macros when writing
configure.ac, since aclocal traces calls to AC_DEFUN but not m4_defun
(and using the low-level names means that aclocal won't automatically
track down where the macros live). But this is one case where the
low-level name saves us, because it means that aclocal no longer tries
to trace it, so that we no longer trip on autoconf's bug when trying to
trace a macro name that requires shell quoting.

[Bruno Haible]

Hi Eric,

Post by Eric Blake

Post by Bruno Haible
Is m4_defun sufficient for AC_REQUIRE to work? The comments state that it is
essential that these macros can be AC_REQUIREd. This is needed for
gl_WARN_ADD (warnings.m4 line 94).

m4_copy([m4_defun], [AC_DEFUN])
that is, AC_DEFUN is defined as a copy of the body of m4_defun,
expanding to the same text. Both AC_REQUIRE and m4_require are equally
happy to pull in a macro, regardless of whether it defined via AC_DEFUN
or m4_defun, making them interchangeable for what output is produced.
Therefore, the difference between the two macros is based solely on the
fact that tracing depends on which macro name is invoked.

Well, then the Autoconf documentation at
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Macro-Definitions.html
is wrong. It states that the major difference between AC_DEFUN and m4_defun
is "some code that is used to constrain the order in which macros are
called, while avoiding redundant output (-> AC_REQUIRE)".

Care to update the documentation?

Bruno

[Eric Blake]

Post by Bruno Haible

Post by Eric Blake
Therefore, the difference between the two macros is based solely on the
fact that tracing depends on which macro name is invoked.

Well, then the Autoconf documentation at
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Macro-Definitions.html
is wrong. It states that the major difference between AC_DEFUN and m4_defun

No, you quoted it wrong. That sentence is describing the difference
between AC_DEFUN and m4_define (not m4_defun). m4_define is low-level
(create a definition, but no hooks for ordering); m4_defun is
higher-level (create a definition AND include hooks for ordering
constraints in that definition).