AC_REQUIRE Behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I?m 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_DEFUN?ed macro that it is AC_REQUIRE?d in. However, it seems like rather
than ensuring that the AC_REQUIRE?d macro has been actually defined within a
scope that the AC_DEFUN?ed macro can access, it just ensures that the first
time that the AC_DEFUN?ed macro is instantiated, the AC_REQUIRE?d macro is
defined if it hasn?t 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 <gwright@xxxxxxxxxxxxxxxxxx>
 
Integrity Applications Incorporated <http://www.integrity-apps.com>
703-378-8672 x260






[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux