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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
