Autoconf Macro Archive
- AM Support
- C++ Support
- C Support
- Fortran Support
- Java Support
- Cross Compilation
- Installed Packages
- LaTeX Support
- archive macros
- adl's macros
- bkorb's macros
- guidod's macros
- latex's macros
- other's macros
- rleigh's macros
- obsoleted macros
- released macros
- search index
- acincludedir m4
- acinclude (tool)
- macro howto
- ax tricks
(C) 2007 guidod
There are a lot of helper macros within the autoconf-2.5x base m4
files that you can reuse. This is largely recommended - this file
just names a few of them which are extra helpful when writing
autoconf extension macros. Note also all the other definitions
that you can find in share/autoconf/autoconf/m4sugar/m4sh.m4
- AS_VAR_PUSHDEF([VAR],[ax_cv_name_$1]) / AS_VAR_POPDEF([VAR])
Macro developers get sometimes into conflict: use a short variable name
and perhaps have name clashes, or use a long name for a shell variable
and make the macro almost unmaintainable. The PUSHDEF/POPDEF is helpful
here, it does even transliterate the right-hand argument to a good name
(if it contains non-alnum characters). Between PUSHDEF and the closing
POPDEF you can then just use VAR and it will be replaced with the long name.
AC_CACHE_CHECK([for $1 available],
If you call AX_CHECK_MACRO(this-test) then `configure` will create a
cache-variable "ax_cv_check_macro_this_test" as a result. (Btw, note
that (a) cache variables needs to have "_cv_" in the name to be saved
and (b) the ax-prefix helps to not clash with names from core autoconf.)
- AC_RUN_LOG([: whatever])
Sometimes you do not want to harrass the final user of a configured
project but still memorize some debugging values somewhere like the
config.log - the autoconf base does not export an extra macro to
write to config.log without showing on the user screen (which would
be done with AC_ECHO/AC_MSG_NOTICE) etc). However you can use a trick
using AC_RUN_LOG - just put a colon ":" up front. This is a builtin
shell command being a "noop", i.e. parse the rest of the line as if
they were arguments for a command, and execute the command ":" which
does simply do nothing at all. As a result ": whatever" will get put
into config.log but nothing else is done, not even a single line
will be seen on stdout.
- proper quoting with  and [VAR] and [[whatever]]
The m4 macro processor will expand everything known as NAME - unlike
shell scripts it is not required to have a "$" in front or some "()"
after it. That's why one should use [..] wherever you want to be
sure that it does not get expanded - e.g. AC_DEFUN(HELLO) might
break havoc if someone else has already defined a HELLO macro as it
would be expanded before AC_DEFUN gets to see the result(!).
Furthmore, if you use arguments on a macro then the arguments are
broken at each ","-comma - that is another problem if the text does
contain some "," which is not unusual in C sources and even some
shell sources. Therefore, -quote non-macro text as often as possible.
And the non-macro text contains some [ ] itself then (e.g. for "sed"
char-ranges) then remember to use [[..]] instead which helps to
preserve a -pair (or all pairs if it used on the whole text block).
Note that the autoconf manual has a lot more to say about m4 quoting.
- breaking lines with "dnl" and dnl'ing m4-managment macros.
Shell text is generally sensitive to line-breaks - it does end a
command. One might try to continue the command line using \ at the
end of the line but you do not need to do that - use can use "dnl"
at the end of the line. This is the "m4" line-comment token as that
the rest of the line will be ignored by m4/autoconf - however it is
different from "#"-shell-comment: the trailing newline will not be
output either. Therefore,
echo the $my_val value happens to dnl
be different than $other_val
will end up in the `configure` script as
echo the $my_val value happens to be different than $other_val
This scheme is also recommended for m4-management lines to prevent them
from issuing unecessary empty lines - which are sometimes even significant
to the bourne-shell or may confuse others. Therefore, have a look above
at the AS_VAR_PUSHDEF example where we did put about a lot of "dnl" to
escape the line-end from being put into the final `configure` script.
- $srcdir and AS_MKDIR_P and AS_BASENAME
Quite some macro developers are not aware that `automake` allows to
emulate the VPATH feature of many `make` engines. This allows to build
the .o object files in a different directory than the .c source file
with a Makefile that looks otherwise as if it is supposed to be in the
source directory. This can be done simple - just create a directory
somewhere and run the `configure` script in there, e.g.
As a macro developer however you should be aware to use $srcdir
whenever you refer to a file from the source arena instead of a file
that you know to be generated during `configure` already. (The
off-source configure is also used in some companies with a readonly
mounted source repository - only in the $builddir you can write any
file anyway). As a side-effect: some developers assume that some
directories do already exist where in they fact they do not. Well,
here we can use the two helper macros AS_MKDIR_P and AS_BASENAME
which emulate `mkdir -p` and `basename` in a portable fashion.
Have other ideas that are both (a) short and (b) especially useful
to the casual macro writer? Please write me: