[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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
> 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:
>   # -----------------------------
>   # 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

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
> 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 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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