[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
rules for m4_require/AC_REQUIRE
From: |
Ralf Wildenhues |
Subject: |
rules for m4_require/AC_REQUIRE |
Date: |
Sun, 6 Nov 2005 13:37:46 +0100 |
User-agent: |
Mutt/1.5.9i |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- rules for m4_require/AC_REQUIRE,
Ralf Wildenhues <=