[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AC_REQUIRE Behavior
From: |
J. Gregory Wright |
Subject: |
AC_REQUIRE Behavior |
Date: |
Thu, 29 Apr 2004 13:43:06 -0400 |
Im a little frustrated by the behavior of AC_REQUIRE() under 2.59. It is
supposed to ensure that a macro has been defined prior to the rest of the
AC_DEFUNed macro that it is AC_REQUIREd in. However, it seems like rather
than ensuring that the AC_REQUIREd macro has been actually defined within a
scope that the AC_DEFUNed macro can access, it just ensures that the first
time that the AC_DEFUNed macro is instantiated, the AC_REQUIREd macro is
defined if it hasnt been already. For example, given a macro like the
following in my acinclude.m4:
AC_DEFUN([AX_MY_MACRO],
[AC_REQUIRE([AC_PROG_EGREP])
AS_IF([eval echo "$1" | $EGREP "my_expr" > /dev/null 2>&1],
[$3],
[$2]
)
])
If later on in configure.ac I have the following logic:
AS_IF([test "x$acx_var_1" = xyes],
[AX_MY_MACRO([arg1],[...],[...])],
[AC_MSG_WARN([...])]
)
AS_IF([test "x$acx_var_2" = xyes],
[AX_MY_MACRO([arg1],[...],[...])]
[AC_MSG_WARN([...])]
)
If $acx_var_1 is no, and $acx_var_2 is yes, then the first invocation of
AX_MY_MACRO does not occur, and the second invocation of AX_MY_MACRO fails
because AC_PROG_EGREP is never invoked - because the shell code generated as
a result of the AC_REQUIRE is within the first conditional. I would prefer
not to call AC_PROG_EGREP directly from the configure.ac, because
acinclude.m4 should be "generic" and a "black box" for configure.ac.
If I leave invoke AC_REQUIRE() as AC_REQUIRE(AC_PROG_EGREP), then what seems
to be the proper code gets put in place, but autoconf throws warnings that
AC_PROG_EGREP is m4_require'd but not m4_defun'ed.
Any suggestions on the right way to handle this would be appreciated.
--
J. Gregory Wright <address@hidden>
Integrity Applications Incorporated <http://www.integrity-apps.com>
703-378-8672 x260
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- AC_REQUIRE Behavior,
J. Gregory Wright <=