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_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. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
