[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_REQUIRE fails to ensure ordering of macros
From: |
Eric Blake |
Subject: |
Re: AC_REQUIRE fails to ensure ordering of macros |
Date: |
Mon, 29 Dec 2008 18:38:43 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Eric Blake <ebb9 <at> byu.net> writes:
>
>
> According to Bruno Haible on 12/26/2008 4:19 AM:
> > The macro gl_PRINTF_ENOMEM in glm4/printf.m4 starts with
> > AC_REQUIRE([AC_PROG_CC])
>
> There's your bug. AC_PROG_CC cannot be AC_REQUIRE'd.
I spoke too soon. AC_PROG_CC can be AC_REQUIRE'd, but it does not always make
sense to do so.
Rather, your bug is the way requirements work. Your code looks like this:
AC_DEFUN([gl_INIT],
[AC_DEFUN([gl_INIT], [
m4_pushdef([AC_LIBOBJ], m4_defn([gl_LIBOBJ]))
...
gl_MULTIARCH
...
gl_FUNC_VASNPRINTF_POSIX
...
])
The way AC_REQUIRE works is that _if_ the macro has not previously been
expanded, then guarantee that the required macro is expanded before the
currently expanded macro. But gl_MULTIARCH has been previously expanded (via
direct expansion, rather than an AC_REQUIRE) by the time you directly expand
gl_FUNC_VASNPRINTF_POSIX.
So, the bug is that gl_INIT is directly expanding AC_DEFUN'd macros which have
AC_REQUIRE dependencies on one another, rather than AC_REQUIRE'ing those macros
in order to ensure that dependencies are sorted out. The rule of thumb is that
IF someone AC_REQUIREs a macro, then EVERYONE should AC_REQUIRE that macro (and
no AC_DEFUN'd body should directly expand it). I think the proper fix is for
gnulib-tool to add AC_REQUIREs around all the macros used in gl_INIT.
--
Eric Blake