On Wed, 9 Feb 2005, Stepan Kasal wrote:
> 1) Let's introduce a macro:
>
> AC_IF(TEST, THEN-CODE, [ELSE-CODE])
>
[...]
>
> 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'.
Of course, wouldn't the people who use normal `if' already be
causing the problem that this macro fixes? I cynically agree with you,
but I'm not sure it's an argument against the macro.
>
>
> 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.
I like this idea too, but I think it handles the following case
less gracefully than would the first idea:
# AC_TEST1 not needed here.
if foo; then
AC_TEST1 # generated here by AC_TEST2 under `if bar'.
if bar; then
AC_TEST2
fi
AC_TEST2 # generated again because of AC_TEST3.
AC_TEST3
fi
Of course, neither of them could handle
#AC_TEST1 not actually needed here.
if foo; then
AC_TEST1 # generated by AC_TEST2
AC_TEST2
fi
if foo; then
# AC_TEST1 and AC_TEST2 not needed.
AC_TEST3
fi
And of course "foo" might not always have the same truth value, so there
isn't a general solution. However, it's worth noting that the AC manual
says under "Here-Documents" that long if-else blocks can be very slow,
thus encouraging exactly this hard-to-handle case. This might be able to
be handled with something like
AC_IF(TEST_ID,TEST,[THEN],[ELSE])
which evaluates TEST only the first time it's expanded for a given
TEST_ID. (Clearly, this does something akin to AC_CACHE_VAL, but
different.) In fact, it would often be the case that the user would know
that TEST had already been evaulated, so perhaps that should be made
optional. Note that I'd make THEN optional because you now have the
option of evaluating TEST early to cache it but without doing anything
about it at that time. I like this solution from the user's perspective,
but I suspect that it does ugly, ugly things to AC_PROVIDE and AC_REQUIRE.
> 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.
Also a good idea. I think my suggestion also wouldn't break
anything if AC_REQUIRE and AC_PROVIDE were defined correctly.
> Both suggestions lead to multiple expansions of AC_TEST2, but I don't
> think this is a big problem. Caching is our friend.
Actually, I think this is explicitly okay, since there are already
cases where you want to use the same test more than once. This brings up
something that's been bothering me: sometimes I want to do something on
the basis of an already-run test, such as if AC_C_STRINGIZE is true or
false. I can use `if test "x$ac_cv_c_stringize" = xyes; then', but with
one big problem: the AC manual never mentions the variable
ac_cv_c_stringize; I had to look at the m4 source to find it. These
things should be documented if they're going to be useful. This is
especially true for this macro, which doesn't take an `IF_TRUE' and
`IF_FALSE' argument.
-Dan
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
