[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recursive AC_CONFIG_COMMANDS_PRE?
From: |
Nick Bowler |
Subject: |
Re: Recursive AC_CONFIG_COMMANDS_PRE? |
Date: |
Sun, 17 Feb 2013 12:20:31 -0500 |
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...
- Re: Recursive AC_CONFIG_COMMANDS_PRE?,
Nick Bowler <=