autoconf: Prerequisite Macros
1
1 10.4.1 Prerequisite Macros
1 --------------------------
1
1 A macro that you write might need to use values that have previously
1 been computed by other macros. For example, `AC_DECL_YYTEXT' examines
1 the output of `flex' or `lex', so it depends on `AC_PROG_LEX' having
1 been called first to set the shell variable `LEX'.
1
1 Rather than forcing the user of the macros to keep track of the
1 dependencies between them, you can use the `AC_REQUIRE' macro to do it
1 automatically. `AC_REQUIRE' can ensure that a macro is only called if
1 it is needed, and only called once.
1
1 -- Macro: AC_REQUIRE (MACRO-NAME)
1 If the M4 macro MACRO-NAME has not already been called, call it
1 (without any arguments). Make sure to quote MACRO-NAME with
1 square brackets. MACRO-NAME must have been defined using
1 `AC_DEFUN' or else contain a call to `AC_PROVIDE' to indicate that
1 it has been called.
1
1 `AC_REQUIRE' must be used inside a macro defined by `AC_DEFUN'; it
1 must not be called from the top level. Also, it does not make
1 sense to require a macro that takes parameters.
1
1 `AC_REQUIRE' is often misunderstood. It really implements
1 dependencies between macros in the sense that if one macro depends upon
1 another, the latter is expanded _before_ the body of the former. To be
1 more precise, the required macro is expanded before the outermost
1 defined macro in the current expansion stack. In particular,
1 `AC_REQUIRE([FOO])' is not replaced with the body of `FOO'. For
1 instance, this definition of macros:
1
1 AC_DEFUN([TRAVOLTA],
1 [test "$body_temperature_in_celsius" -gt "38" &&
1 dance_floor=occupied])
1 AC_DEFUN([NEWTON_JOHN],
1 [test "x$hair_style" = xcurly &&
1 dance_floor=occupied])
1
1 AC_DEFUN([RESERVE_DANCE_FLOOR],
1 [if date | grep '^Sat.*pm' >/dev/null 2>&1; then
1 AC_REQUIRE([TRAVOLTA])
1 AC_REQUIRE([NEWTON_JOHN])
1 fi])
1
1 with this `configure.ac'
1
1 AC_INIT([Dance Manager], [1.0], [bug-dance@example.org])
1 RESERVE_DANCE_FLOOR
1 if test "x$dance_floor" = xoccupied; then
1 AC_MSG_ERROR([cannot pick up here, let's move])
1 fi
1
1 does not leave you with a better chance to meet a kindred soul at other
1 times than Saturday night since it expands into:
1
1 test "$body_temperature_in_Celsius" -gt "38" &&
1 dance_floor=occupied
1 test "x$hair_style" = xcurly &&
1 dance_floor=occupied
1 fi
1 if date | grep '^Sat.*pm' >/dev/null 2>&1; then
1
1
1 fi
1
1 This behavior was chosen on purpose: (i) it prevents messages in
1 required macros from interrupting the messages in the requiring macros;
1 (ii) it avoids bad surprises when shell conditionals are used, as in:
1
1 if ...; then
1 AC_REQUIRE([SOME_CHECK])
1 fi
1 ...
1 SOME_CHECK
1
1 However, this implementation can lead to another class of problems.
1 Consider the case where an outer macro first expands, then indirectly
1 requires, an inner macro:
1
1 AC_DEFUN([TESTA], [[echo in A
1 if test -n "$SEEN_A" ; then echo duplicate ; fi
1 SEEN_A=:]])
1 AC_DEFUN([TESTB], [AC_REQUIRE([TESTA])[echo in B
1 if test -z "$SEEN_A" ; then echo bug ; fi]])
1 AC_DEFUN([TESTC], [AC_REQUIRE([TESTB])[echo in C]])
1 AC_DEFUN([OUTER], [[echo in OUTER]
1 TESTA
1 TESTC])
1 OUTER
1
1 Prior to Autoconf 2.64, the implementation of `AC_REQUIRE' recognized
1 that `TESTB' needed to be hoisted prior to the expansion of `OUTER',
1 but because `TESTA' had already been directly expanded, it failed to
1 hoist `TESTA'. Therefore, the expansion of `TESTB' occurs prior to its
1 prerequisites, leading to the following output:
1
1 in B
1 bug
1 in OUTER
1 in A
1 in C
1
1 Newer Autoconf is smart enough to recognize this situation, and hoists
1 `TESTA' even though it has already been expanded, but issues a syntax
1 warning in the process. This is because the hoisted expansion of
1 `TESTA' defeats the purpose of using `AC_REQUIRE' to avoid redundant
1 code, and causes its own set of problems if the hoisted macro is not
1 idempotent:
1
1 in A
1 in B
1 in OUTER
1 in A
1 duplicate
1 in C
1
1 The bug is not in Autoconf, but in the macro definitions. If you
1 ever pass a particular macro name to `AC_REQUIRE', then you are implying
1 that the macro only needs to be expanded once. But to enforce this,
1 either the macro must be declared with `AC_DEFUN_ONCE' (although this
1 only helps in Autoconf 2.64 or newer), or all uses of that macro should
1 be through `AC_REQUIRE'; directly expanding the macro defeats the point
1 of using `AC_REQUIRE' to eliminate redundant expansion. In the
1 example, this rule of thumb was violated because `TESTB' requires
1 `TESTA' while `OUTER' directly expands it. One way of fixing the bug
1 is to factor `TESTA' into two macros, the portion designed for direct
1 and repeated use (here, named `TESTA'), and the portion designed for
1 one-shot output and used only inside `AC_REQUIRE' (here, named
1 `TESTA_PREREQ'). Then, by fixing all clients to use the correct
1 calling convention according to their needs:
1
1 AC_DEFUN([TESTA], [AC_REQUIRE([TESTA_PREREQ])[echo in A]])
1 AC_DEFUN([TESTA_PREREQ], [[echo in A_PREREQ
1 if test -n "$SEEN_A" ; then echo duplicate ; fi
1 SEEN_A=:]])
1 AC_DEFUN([TESTB], [AC_REQUIRE([TESTA_PREREQ])[echo in B
1 if test -z "$SEEN_A" ; then echo bug ; fi]])
1 AC_DEFUN([TESTC], [AC_REQUIRE([TESTB])[echo in C]])
1 AC_DEFUN([OUTER], [[echo in OUTER]
1 TESTA
1 TESTC])
1 OUTER
1
1 the resulting output will then obey all dependency rules and avoid any
1 syntax warnings, whether the script is built with old or new Autoconf
1 versions:
1
1 in A_PREREQ
1 in B
1 in OUTER
1 in A
1 in C
1
1 The helper macros `AS_IF' and `AS_CASE' may be used to enforce
1 expansion of required macros outside of shell conditional constructs.
1 You are furthermore encouraged, although not required, to put all
1 `AC_REQUIRE' calls at the beginning of a macro. You can use `dnl' to
1 avoid the empty lines they leave.
1