On 08/27/2017 12:50 PM, Bruno Haible wrote:
>> 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.6
Hi Eric,
> > 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
On 08/25/2017 01:43 AM, Bruno Haible wrote:
>> # 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_ERROR
Hi Eric,
> @@ -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
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 autom4t
