rules for m4_require/AC_REQUIRE

[Ralf Wildenhues]

It's almost never right to change a macro call into a macro requirement.
It does hideous things!  We've had three bugs at least now because of
those!

Proposed rules for defun'ed macros:

Rule #1:
Do not m4_defun/AC_DEFUN a macro unless all its requirements obey the
following rules recursively.  Use m4_define instead to define the macro,
so that nobody can require your macro by mistake.

Rule #2:
*ALL* macros whose expansions need to come before the macro are listed
as requirements (m4_require/AC_REQUIRE).

Rule #3:
All requirement *MUST* be listed at the very beginning of the macro body.
If they aren't, you have a thinko.  Start over again.

Rule #4:
The order of the requirement listing is *IMPORTANT*, as it is used for
partial ordering!  Nonetheless, it is not a suitable substitute for
missing requirement listing in the respective macros!

Rule #5:
The macro is stateless: its name (or the second argument to the require
call, FWIW) is all it needs for its effect + side-effects to be the
same.  IOW: If it's ever to be called again, it would not matter: the
result would be the same as if it weren't.

Rule #6:
Consequence of #5: It makes little sense to ever explicitly call a macro
that is also required.


Comments appreciated.  Rule #1 contradicts current Autoconf docs, #6
contradicts what we have in Libtool at the moment (to some extent)

Cheers,
Ralf