Re: AC_REQUIRE fails to ensure ordering of macros

[Eric Blake]

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