6.3.3 Writing your own aclocal macros

The aclocal program doesn’t have built-in knowledge of any macros. You can extend it with your own macros.

Libraries, for example, usually want to supply their own Autoconf macros for use by other programs. For instance, the gettext library supplies a macro AM_GNU_GETTEXT that should be used by any package using gettext. When the library is installed, it installs this macro so that aclocal will find it.

A macro file’s name should end in .m4. Such files should be installed in $(datadir)/aclocal. This can be done with:

aclocaldir = $(datadir)/aclocal
aclocal_DATA = mymacro.m4 myothermacro.m4

Please do use $(datadir)/aclocal, and not something based on the result of ‘aclocal --print-ac-dir’ (see Installing to Hard-Coded Locations, for arguments). It might also be helpful to suggest to the user to add the $(datadir)/aclocal directory to their ACLOCAL_PATH variable (see ACLOCAL_PATH) so that aclocal will find the .m4 files installed by your package automatically.

A file of macros should be a series of properly quoted AC_DEFUN’s (see Macro Definitions in The Autoconf Manual). The aclocal program also understands AC_REQUIRE (see Prerequisite Macros in The Autoconf Manual), so it is safe to put each macro in a separate file. Each file should have no side effects except for defining the macro(s). In particular, any call to AC_PREREQ should be done inside the defined macro, not at the beginning of the file.

Starting with Automake 1.8, aclocal warns about all underquoted calls to AC_DEFUN. We realize this annoys some people, because aclocal was not so strict in the past and many third party macros are underquoted; and we have to apologize for this temporary inconvenience. The reason we have to be stricter is that a possible future implementation of aclocal (see The Future of aclocal) will have to temporarily include all of these third party .m4 files, maybe several times, even including files that end up not being needed. Doing so should alleviate many problems of the current implementation; however, it requires a stricter style from macro authors. Hopefully it is easy to revise the existing macros. For instance,

# bad style
AC_PREREQ(2.68)
AC_DEFUN(AX_FOOBAR,
[AC_REQUIRE([AX_SOMETHING])dnl
AX_FOO
AX_BAR
])

should be rewritten as

AC_DEFUN([AX_FOOBAR],
[AC_PREREQ([2.68])dnl
AC_REQUIRE([AX_SOMETHING])dnl
AX_FOO
AX_BAR
])

Wrapping the AC_PREREQ([2.68]) call inside the macro ensures that the Autoconf 2.68 will not be a prerequisite if AX_FOOBAR is not used. Most importantly, quoting the first argument of AC_DEFUN allows the macro to be redefined or included twice (otherwise this first argument would be expanded during the second definition). For consistency we like to quote even arguments such as 2.68 that do not require it.

If you have been directed here by the aclocal diagnostic but are not the maintainer of the implicated macro, you will want to contact the maintainer of that macro. Please try to make sure you have the latest version of the macro and that the problem hasn’t already been reported before doing so.

Another situation where aclocal is commonly used is to manage macros that are used locally by the package; Handling Local Macros.