The Autoconf language differs from many other computer languages because it treats actual code the same as plain text. Whereas in C, for instance, data and instructions have different syntactic status, in Autoconf their status is rigorously the same. Therefore, we need a means to distinguish literal strings from text to be expanded: quotation.
When calling macros that take arguments, there must not be any white space between the macro name and the open parenthesis.
AC_INIT ([oops], [1.0]) # incorrect AC_INIT([hello], [1.0]) # good
Arguments should be enclosed within the quote characters ‘[’ and ‘]’, and be separated by commas. Any leading blanks or newlines in arguments are ignored, unless they are quoted. You should always quote an argument that might contain a macro name, comma, parenthesis, or a leading blank or newline. This rule applies recursively for every macro call, including macros called from other macros. For more details on quoting rules, see Programming in M4.
AC_CHECK_HEADER([stdio.h], [AC_DEFINE([HAVE_STDIO_H], , [Define to 1 if you have <stdio.h>.])], [AC_MSG_ERROR([sorry, can't do anything for you])])
is quoted properly. You may safely simplify its quotation to:
AC_CHECK_HEADER([stdio.h], [AC_DEFINE([HAVE_STDIO_H], 1, [Define to 1 if you have <stdio.h>.])], [AC_MSG_ERROR([sorry, can't do anything for you])])
because ‘1’ cannot contain a macro call. Here, the argument of
AC_MSG_ERROR must be quoted; otherwise, its comma would be
interpreted as an argument separator. Also, the second and third arguments
of ‘AC_CHECK_HEADER’ must be quoted, since they contain
macro calls. The three arguments ‘HAVE_STDIO_H’, ‘stdio.h’,
and ‘Define to 1 if you have <stdio.h>.’ do not need quoting, but
if you unwisely defined a macro with a name like ‘Define’ or
‘stdio’ then they would need quoting. Cautious Autoconf users
would keep the quotes, but many Autoconf users find such precautions
annoying, and would rewrite the example as follows:
AC_CHECK_HEADER(stdio.h, [AC_DEFINE(HAVE_STDIO_H, 1, [Define to 1 if you have <stdio.h>.])], [AC_MSG_ERROR([sorry, can't do anything for you])])
This is safe, so long as you adopt good naming conventions and do not define macros with names like ‘HAVE_STDIO_H’, ‘stdio’, or ‘h’. Though it is also safe here to omit the quotes around ‘Define to 1 if you have <stdio.h>.’ this is not recommended, as message strings are more likely to inadvertently contain commas.
The following example is wrong and dangerous, as it is underquoted:
AC_CHECK_HEADER(stdio.h, AC_DEFINE(HAVE_STDIO_H, 1, Define to 1 if you have <stdio.h>.), AC_MSG_ERROR([sorry, can't do anything for you]))
In other cases, you may have to use text that also resembles a macro
call. You must quote that text even when it is not passed as a macro
argument. For example, these two approaches in configure.ac
(quoting just the potential problems, or quoting the entire line) will
protect your script in case autoconf ever adds a macro
echo "Hard rock was here! --[AC_DC]" [echo "Hard rock was here! --AC_DC"]
which results in this text in configure:
echo "Hard rock was here! --AC_DC" echo "Hard rock was here! --AC_DC"
When you use the same text in a macro argument, you must therefore have an extra quotation level (since one is stripped away by the macro substitution). In general, then, it is a good idea to use double quoting for all literal string arguments, either around just the problematic portions, or over the entire argument:
AC_MSG_WARN([[AC_DC] stinks --Iron Maiden]) AC_MSG_WARN([[AC_DC stinks --Iron Maiden]])
However, the above example triggers a warning about a possibly unexpanded macro when running autoconf, because it collides with the namespace of macros reserved for the Autoconf language. To be really safe, you can use additional escaping (either a quadrigraph, or creative shell constructs) to silence that particular warning:
echo "Hard rock was here! --AC""_DC" AC_MSG_WARN([[AC@&t@_DC stinks --Iron Maiden]])
You are now able to understand one of the constructs of Autoconf that has been continually misunderstood... The rule of thumb is that whenever you expect macro expansion, expect quote expansion; i.e., expect one level of quotes to be lost. For instance:
AC_COMPILE_IFELSE([char b;], , [AC_MSG_ERROR([you lose])])
is incorrect: here, the first argument of
‘char b;’ and is expanded once, which results in
‘char b10;’. (There was an idiom common in Autoconf's past to
address this issue via the M4
changequote primitive, but do not
use it!) Let's take a closer look: the author meant the first argument
to be understood as a literal, and therefore it must be quoted twice:
AC_COMPILE_IFELSE([[char b;]], , [AC_MSG_ERROR([you lose])])
Voilà, you actually produce ‘char b;’ this time!
On the other hand, descriptions (e.g., the last parameter of
AS_HELP_STRING) are not literals—they
are subject to line breaking, for example—and should not be double quoted.
Even if these descriptions are short and are not actually broken, double
quoting them yields weird results.
Some macros take optional arguments, which this documentation represents as [arg] (not to be confused with the quote characters). You may just leave them empty, or use ‘’ to make the emptiness of the argument explicit, or you may simply omit the trailing commas. The three lines below are equivalent:
AC_CHECK_HEADERS([stdio.h], , , ) AC_CHECK_HEADERS([stdio.h],,,) AC_CHECK_HEADERS([stdio.h])
It is best to put each macro call on its own line in configure.ac. Most of the macros don't add extra newlines; they rely on the newline after the macro call to terminate the commands. This approach makes the generated configure script a little easier to read by not inserting lots of blank lines. It is generally safe to set shell variables on the same line as a macro call, because the shell allows assignments without intervening newlines.
You can include comments in configure.ac files by starting them with the ‘#’. For example, it is helpful to begin configure.ac files with a line like this:
# Process this file with autoconf to produce a configure script.