Re: Recursive AC_CONFIG_COMMANDS_PRE?

[Nick Bowler]

Hi Eric, sorry for the delay.

On 2013-01-24, Eric Blake <address@hidden> wrote:
> On 01/23/2013 09:16 PM, Nick Bowler wrote:
[...]
> > A more complicated option would be a sort of "recursive"
> > expansion of AC_OUTPUT_COMMANDS_PRE, such that invocations of
> > AC_CONFIG_COMMANDS_PRE during the expansion are collected as usual,
> > then *those* commands are expanded after the current expansion of
> > AC_OUTPUT_COMMANDS_PRE, and so on until there are no more commands.
> > I modified lib/autoconf/status.m4 to do just that, by defining the
> > following helper macro:
> >
> >   # AC_OUTPUT_COMMANDS_REC(MACRO)
> >   # -----------------------------
> >   # Until the definition of MACRO is empty, repeatedly expand MACRO
> >   # in a context where it has been redefined to the empty string.
> >   m4_define([AC_OUTPUT_COMMANDS_REC], [m4_ifnblank(m4_defn([$1]),
> >   [m4_define([$1], [m4_define([$1])]m4_defn([$1]))
> >   m4_indir([$1])dnl
> >   AC_OUTPUT_COMMANDS_REC([$1])])])
>
> Cute.  Might be worth moving into the m4sugar 'm4_' namespace instead of
> the 'AC_' namespace; and as written it adds spurious whitespace into the
> output file, but it looks like a reasonable approach.

Indeed, it seems like one of the dnls vanished while I was revising.  I
presume that's the only spurious whitespace problem.  Easily fixed.

> > This seems to work just fine, although we could imagine some
> > (crazy!) configure scripts for which this change makes them
> > non-terminating...
>
> It's already possible to write configure.ac that causes an infinite
> loop [or fill the disk or exhaust memory], and autoconf is not in the
> business of solving the "halting problem".  So we don't really have to
> worry about such buggy input.

I agree that the case is not worth worrying about.  Just doing my due
diligence to consider potential backwards incompatibilities.

> I think making AC_OUTPUT_COMMANDS_PRE behave more like atexit(3) (where
> additional clauses are requested during the execution of an existing
> clause) makes sense.  Now to turn your suggestion into an actual patch...

I finally managed to get a round tuit.  Will follow up with a patch...