Hi, we all know about the following problem: if test $enable_foo = yes; then AC_TEST2 fi ... AC_TEST3 If AC_TEST2 and AC_TEST3 both require AC_TEST1, then it's expanded just before AC_TEST2, which breaaks the script in cases when $enable_foo != yes. Or perhaps AC_TEST3 requires AC_TEST2 and we have a similar problem. Wouldn't it be possible to fix this somehow? I have two ideas: 1) Let's introduce a macro: AC_IF(TEST, THEN-CODE, [ELSE-CODE]) The macro would be AC_DEFUNd, so all AC_REQUIREd macros would go before the shell `if' and would be executed unconditionally. The macro AC_IF would also redefine m4_provide, so that macros expanded inside the shell if wouldn't be provided; if a later macro requires them, they would be expanded unconditionaly. With the example above (where AC_TESTx requires AC_TESTy iff x>y), we'd get: AC_TEST1 if test $enable_foo = yes; then AC_TEST2 fi ... AC_TEST2 AC_TEST3 The problem with this is that it would be probably next to impossible to teach people to use AC_IF instead of a normal `if'. 2) Let's define AC_REQUIRE in a way similar to AS_REQUIRE: all required macros would go to a certain place near the top. And if a macro were expanded in the ``main'' diversion, it wouldn't be provided. Only AC_REQUIRE call would call m4_provide for the macro. So our example would end up like this: AC_TEST1 AC_TEST2 ... if test $enable_foo = yes; then AC_TEST2 fi ... AC_TEST3 This second approach has bigger chance to break existing script; it might be possible to introduce this kind of dependency with a new name, perhaps AC_PREREQ, ``prerequired'' macros. Both suggestions lead to multiple expansions of AC_TEST2, but I don't think this is a big problem. Caching is our friend. Happy auto*$#ing, Stepan Kasal _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
