Re: [BUG] AC_PATH_XTRA

[Akim Demaille]

| 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!