AC_REQUIRE problems

[Stepan Kasal]

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