| Hi,
| given this configure.in (a useless case, but it'll serve as an
| example):
|
| == [snip] ====================================
|
| AC_INIT(configure.in)
| AC_CONFIG_HEADER(config.h)
|
| if false; then
| AC_PATH_XTRA
| else
| AC_PATH_XTRA
| fi
|
| AC_OUTPUT
|
|
| == [snip] ====================================
|
| ..the resulting configure script will fail to define X_DISPLAY_MISSING
| on systems without X11.
|
| The reason for this is that AC_PATH_XTRA AC_REQUIREs AC_PATH_X, which
| means it will only get expanded for the _first_ AC_PATH_XTRA in the
| configure.in above, and then AC_PATH_XTRA uses
|
| test x"$no_x" = xyes
|
| to decide whether or not to define X_DISPLAY_MISSING. But the
| AC_PATH_X code will never be executed for the second AC_PATH_XTRA
| above, so $no_x will never be set to anything at all.
This is a bad trap, agreed, but it's known and people have to be aware
of it.
Prerequisite Macros
-------------------
A macro that you write might need to use values that have previously
been computed by other macros. For example, `AC_DECL_YYTEXT' examines
the output of `flex' or `lex', so it depends on `AC_PROG_LEX' having
been called first to set the shell variable `LEX'.
Rather than forcing the user of the macros to keep track of the
dependencies between them, you can use the `AC_REQUIRE' macro to do it
automatically. `AC_REQUIRE' can ensure that a macro is only called if
it is needed, and only called once.
- Macro: AC_REQUIRE (MACRO-NAME)
If the M4 macro MACRO-NAME has not already been called, call it
(without any arguments). Make sure to quote MACRO-NAME with
square brackets. MACRO-NAME must have been defined using
`AC_DEFUN' or else contain a call to `AC_PROVIDE' to indicate that
it has been called.
`AC_REQUIRE' must be used inside an `AC_DEFUN''d macro, it must
not be called from the top level.
`AC_REQUIRE' is often misunderstood, it really implements
dependencies between macros in the sense that if a macro depends upon
another, the latter will be expanded _before_ the body of the former.
In particular, `AC_REQUIRE(FOO)' is not replaced with the body of
`FOO'. For instance, this definition of macros
AC_DEFUN([TRAVOLTA],
[test "$body_temparature_in_celsius" -gt "38" &&
dance_floor=occupied])
AC_DEFUN([NEWTON_JOHN],
[test "$hair_style" = "curly" &&
dance_floor=occupied])
AC_DEFUN([RESERVE_DANCE_FLOOR],
[if date | grep '^Sat.*pm' >/dev/null 2>&1; then
AC_REQUIRE([TRAVOLTA])
AC_REQUIRE([NEWTON_JOHN])
fi])
with this `configure.in'
AC_INIT
RESERVE_DANCE_FLOOR
if test "$dance_floor" = occupied; then
AC_MSG_ERROR([cannot pick up here, let's move])
fi
will not leave you with a better chance to meet the kindred soul the
other times that the Saturday night since it expands into:
test "$body_temperature_in_Celsius" -gt "38" &&
dance_floor=occupied
test "$hair_style" = "curly" &&
dance_floor=occupied
fi
if date | grep '^Sat.*pm' >/dev/null 2>&1; then
fi
This behavior was chosen on purpose: (i) it avoids that messages from
required macros interrupt the messages from the requiring macros, (ii),
it avoids bad surprises when shell conditionals are used, as in:
if ...; then
AC_REQUIRE([SOME_CHECK])
fi
...
SOME_CHECK
You are encouraged to put all the `AC_REQUIRE's at the beginning of
the macros. You can use `dnl' to avoid the empty line they leave.
(I agree the examples are very bad, if someone has something more
funny, I'm interested! :)
What would you suggest in this precise case?
| (Autoconf's X11 checking is in general a mess, BTW.)
Ooooooooooh, yes, it is!
