Hello, On Wed, Jul 13, 2005 at 07:38:25AM -0400, Bob Rossi wrote: > Is this a bug in autoconf? yes, this is a bug in autoconf. It is well known, and it'll be fixed in Autoconf 3, in a distant future... The problem is misinteraction between the two layers of autoconf, the m4 expansion and the shell execution. Some m4 macros should be expanded only once. When m4 is about to expand such a macro, and it notices that it was already expanded before, it won't expand it again. But if the previous expansion was skipped, because it was inside an `if', tthe macro is not run at all, which is wrong. The most common incarnation is AC_REQUIRE. AC_REQUIRE([FOO]) means: if FOO was not expanded yet, put it just before the macro we are currently in. So I guess there is a macro which is required (perhaps indirectly) both by the VL_* macro inside the `if' and by some of the three macros you moved. In the previous version, VL_* caused that the reauired macro went inside the `if' and the later AC_REQUIRE in the "three macros" didn't cause any expansion. In your fixed version, the required macro was expanded just before one of the "three macros", thus it is always executed. > I would really like to get to the root of > this problem, so that others do not have to deal with it, ever. I'm afraid there is no easy fix for the problem within Autoconf 2.x. The problem is that Autoconf 2 doesn't use shell functions, for portability reasons. Autoconf 3 will allow shell functions. With these, AC_REQUIRE([FOO]) will be re-implemented to something like this: $ac_done_FOO ac_mac_FOO Shell function ac_mac_FOO will contain the body of FOO and will be defined near the top of configure. Variable ac_done_FOO will be initially an empty string, but ac_mac_FOO will set it to ":", so the function will be executed only once. When I see this solution, I don't think it's worth it to waste much time trying to find a suitable solution for Autoconf 2, though I understand that this bug can be very annoyig. But hey, this bug forced you to learn more about Autoconf, right? ;-) No seriously, we apologize for the inconvenience, but we are afraid there is no instant solution. (Except the workaround described by Andreas, which you actually use.) Have nice day, Stepan Kasal _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf