>>>>> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> IMHO, AC_REQUIRE and AC_BEFORE are broken by design.
Sorry, but I find your judgment a bit severe.
dv> Or at least, their behavior is far too basic (notably the calling
dv> of the required macro without any argument)to be satisfactory
dv> outside the scope of Autoconf's internals.
AC_REQUIRE is nothing but an optimization. If you rely on the results
of some tests that need to be run before, just run the tests in your
macro.
In fact, the real motivation for AC_REQUIRE, as you may know, was not
optimizing etc. it was just a means to easily call other tests within
some tests *without having the `checking... yes' messages overlap*.
Autoconf does not need AC_REQUIRE at all. But it's convenient.
dv> All of this could probably be implemented with a new set of macros
dv> (pain with the macros names coming soon...). However, there is
dv> something that I consider as a real bug in the current interface:
dv> if the macro A requires the macro B, and the macro B is present in
dv> configure.in after A, A should not just call B. It should abort at
dv> autoconf time and nicely ask the package writer to switch the two
dv> calls.
I personally don't agree. The declarative and almost commutative
nature of configure.in is a strength of Autoconf, and I'd like to keep
it like this. I see no reason for people to learn too much about
Autoconf, we are here to this end. And having to learn an order is
definitely amongst the less fruitful things to learn.
As far as requiring with arguments, it is something which is planned
in the future of Autoconf, but we are cooling down the development for
2.15.
But remember: that's an optimization, nothing else. If you rely on a
test, run that test.
Akim
