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
[email protected]
http://lists.gnu.org/mailman/listinfo/autoconf
