Re: AC_REQUIRE fails to ensure ordering of macros

[Bruno Haible]

Eric Blake wrote:
> Here's what I'm committing as a first round of documentation.

The clarifications about macros with arguments are indisputable; thanks.

Regarding the AC_REQUIRE "bug", you write:

> If you ever
> pass a particular macro name to @code{AC_REQUIRE}, then you are implying
> that the macro only needs to be expanded once.  But to enforce this, all
> uses of that macro should be through @code{AC_REQUIRE}

This means that there are basically two categories of AC_DEFUNed macros
without arguments: those which are meant to be invoked, and those which are
meant to be AC_REQUIREd. This raises even more questions:
  - Wouldn't it be better to define them clearly using two different syntaxes,
    say, AC_DEFUN for one, and AC_DEFREQ for the other?
  - To which category does AC_PROG_EGREP belong? And what about AC_PROG_CC?
    And AC_CANONICAL_HOST? Etc.

IMO, this is a slippery slope that leads to an autoconf that is worse than
the one we have today.

How about solving the problem differently? You say:

> If you ever
> pass a particular macro name to @code{AC_REQUIRE}, then you are implying
> that the macro only *needs* to be expanded once.

The emphasis lies on "needs to", not "must". How about allowing a duplicate
expansion in this case? Most autoconf macros without arguments are
idempotents, i.e. executing them twice has the same effect as executing
them once. Your example

AC_DEFUN([A], [[in A]])
AC_DEFUN([B], [AC_REQUIRE([A])[in B]])
AC_DEFUN([C], [AC_REQUIRE([B])[in C]])
AC_DEFUN([OUTER], [[in OUTER]
A
C])
OUTER

could then lead to the output

in A
in B
in OUTER
in A
in C

You can implement this with the known techniques of stacks and diversions.
When in the expansion of B, autoconf notices AC_REQUIRE([A]), it knows that
A has already been expanded, but also that its expansion comes after the
diversion to which B is being sent; therefore it requests another expansion
of A.

Bruno