[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recursive AC_CONFIG_COMMANDS_PRE?
From: |
Eric Blake |
Subject: |
Re: Recursive AC_CONFIG_COMMANDS_PRE? |
Date: |
Thu, 24 Jan 2013 06:24:55 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 01/23/2013 09:16 PM, Nick Bowler wrote:
> Hello Autoconfers,
>
> I recently ran into an issue where the actions I had configured with
> AC_CONFIG_COMMANDS_PRE from a macro were not actually being output to
> the configure script. When I investigated, I noticed that the macro in
> question was itself invoked inside an AC_CONFIG_COMMANDS_PRE command;
> but as there was quite a bit of indirection involved this fact was not
> immediately obvious.
>
> Currently, Autoconf accepts the above configure script as it does not
> execute the m4_fatal call. This happens mainly due to the simplicity
> of AC_CONFIG_COMMANDS_PRE: each invocation appends the argument to one
> big macro which is then expanded once near the end. Any calls to
> AC_CONFIG_COMMANDS_PRE that occur during this expansion still append
> to that macro, but since it has already been expanded at this point
> those don't go anywhere useful.
Nice analysis.
> 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.
>
> and replacing the call to AC_OUTPUT_COMMANDS_PRE() with
> AC_OUTPUT_COMMANDS_REC([AC_OUTPUT_COMMANDS_PRE]). The same change could
> be done for AC_CONFIG_COMMANDS_POST. 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.
>
> Any thoughts?
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...
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature