[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
> 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], [
  m4_pushdef([AC_LIBOBJ], m4_defn([gl_LIBOBJ]))

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 

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]