Re: weird AC_REQUIRE expansion issue

[Stepan Kasal]

Hello Ralf,

*warning*: my previous long answer was not correct!

And at the beginning of the long answer, I recommended:
        AC_REQUIRE([_CX_STATUS_FOR_CX_COMPILER_CHECKS])

(you have to define the temporary macro _CX_STATUS_FOR_CX_COMPILER_CHECKS).
This suggestion was correct.  Use it if you can.

If you cannot, please post a self-contained example, or point me to the
real CVS where you experienced it.

If you are not interested in Autoconf internals and future evolution, you can
skip the rest of the mail. (Except the wish to "have a nice day", of course.)

In my "short answer", I recommended:
        AC_REQUIRE([CX_STATUS([compiler checks])])

This suggestion was not correct, because m4_require doesn't call m4_provide.
So you would have to call:
        AC_REQUIRE([CX_STATUS([compiler checks])])
        AC_PROVIDE([CX_STATUS([compiler checks])])

But this is not documented.  When I think about it, perhaps we shouldn't
document it.  The documentation says the parameter has to be name of an
(AC_DEFUNed) macro.  And I think AC_REQUIRE should be that strict, it could
even _check_ it.

And I think that AC_PROVIDE could be marked obsolete.

All the flexibility would be still available with m4_require/m4_provide.
Moreover, I think that m4_require should call m4_provide([$1]).

With this change (and with s/AC_REQUIRE/m4_require/), all the text of my
previous mail would be true.

On Wed, Aug 31, 2005 at 01:53:07PM +0200, Ralf Wildenhues wrote:
> But a question for now: Can I assume the second parameters of both
> AC_REQUIRE and m4_require to be public interface?

I seems I have just decided to change it!  Lucky it wasn't documented!

The fact that Autoconf users squeeze me asking what is documented and
what isn't is two-edged: I'm no longer ashamed to change things which
are not documented.  ;-)

I'll make a patch implementing these ideas, eventually.

Have a nice day,
        Stepan