Re: aclocal problems
http://thread.gmane.org/gmane.comp.sysutils.automake.general/10429/focus=10431
Hi Eric, John,
* John Calcote wrote on Sat, Apr 04, 2009 at 06:55:46AM CEST:
On 4/3/2009 5:31 PM, Ralf Wildenhues wrote:
* John Calcote wrote on Fri, Apr 03, 2009 at 09:33:40PM CEST:
On page 158, paragraph 3 of the 2.63 Autoconf manual, it states:
If a macro doesn’t use AC_REQUIRE, is expected to never be the object
of an AC_REQUIRE directive, and macros required by other macros inside
arguments do not need to be expanded before this macro, then use
m4_define.
...
Is this a bug in aclocal?
I don't think so. Do you think the quote is an encouragement not to use
AC_REQUIRE?
Hmmm. No, I don't think it's an encouragement not to use AC_REQUIRE.
[...]
I agree completely with your assessment, but I think the manual should
make it clear that the only proper way to write a macro is with
AC_DEFUN, don't you? I mean, if the only way I can write a macro outside
of adding it directly to configure.ac (which is pointless in all but the
strangest cases) is to use AC_DEFUN, then *when* would I ever be able to
successfully use m4_define? I suppose it might work in acsite.m4, as
that's not included by aclocal.m4.
My only point is that the manual is a bit unclear on this point - almost
misleading, in fact.
I'd call it a documentation bug at this point. (Eric - comments?)
Good point. Public third-party macros should be AC_DEFUNed for this
reason. OK to apply?
Thanks,
Ralf
Note that AC_DEFUN is needed for aclocal.
* doc/autoconf.texi (Coding Style): Public third-party macros
should be AC_DEFUN'ed.
Report by John Calcote.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 47c4c24..d715fe4 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -13554,6 +13554,9 @@ macro doesn't use @code{AC_REQUIRE}, is expected to
never be the object
of an @code{AC_REQUIRE} directive, and macros required by other macros
inside arguments do not need to be expanded before this macro, then
use @code{m4_define}. In case of doubt, use @code{AC_DEFUN}.
+Also take into account that public third-party macros need to use
+...@code{ac_defun} in order to be found by @command{aclocal}
+(@pxref{Extending aclocal,,, automake, @acronym{GNU} Automake}).
All the @code{AC_REQUIRE} statements should be at the beginning of the
macro, and each statement should be followed by @code{dnl}.
Re: aclocal problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/10/2009 12:32 AM: http://thread.gmane.org/gmane.comp.sysutils.automake.general/10429/focus=10431 I'd call it a documentation bug at this point. (Eric - comments?) Sorry for missing this thread; I tend not to follow automake lists as closely. Good point. Public third-party macros should be AC_DEFUNed for this reason. OK to apply? Yes, please. But given the recent thread about AC_DEFUN being able to hoist contents while m4_define does not, would it ever make sense to add a macro in the AC_ namespace that is equivalent to m4_define but still traced by aclocal? Unfortunately, the name AC_DEFINE is already claimed. Note that AC_DEFUN is needed for aclocal. * doc/autoconf.texi (Coding Style): Public third-party macros should be AC_DEFUN'ed. Report by John Calcote. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknfN5oACgkQ84KuGfSFAYCbTACg0ghaOXc/lUbR1SxwZSrPNtj1 q9AAniHwaFAccUoCf/EkgoIZEq3lppyw =VbAT -END PGP SIGNATURE-
Re: aclocal problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/10/2009 12:32 AM: http://thread.gmane.org/gmane.comp.sysutils.automake.general/10429/focus=10431 Hi Eric, John, * John Calcote wrote on Sat, Apr 04, 2009 at 06:55:46AM CEST: On 4/3/2009 5:31 PM, Ralf Wildenhues wrote: * John Calcote wrote on Fri, Apr 03, 2009 at 09:33:40PM CEST: On page 158, paragraph 3 of the 2.63 Autoconf manual, it states: If a macro doesn’t use AC_REQUIRE, is expected to never be the object of an AC_REQUIRE directive, and macros required by other macros inside arguments do not need to be expanded before this macro, then use m4_define. By the way, you may be interested in seeing how I was able to use m4_define and still get aclocal to use my file for gnulib's AC_DEFUN_ONCE replacement (coupled with an AC_REQUIRE([gl_00GNULIB]) in gnulib-common.m4): http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/00gnulib.m4 http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=fcf62c3d - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknfRMUACgkQ84KuGfSFAYD3igCdH4Pq/gX2zb5pEE6CtdaCXS1S W2MAoIeXYNMQRTP4G9TeMKfaFt/Um5KL =Yb+w -END PGP SIGNATURE-
Re: aclocal problems
* Eric Blake wrote on Fri, Apr 10, 2009 at 02:12:10PM CEST: According to Ralf Wildenhues on 4/10/2009 12:32 AM: http://thread.gmane.org/gmane.comp.sysutils.automake.general/10429/focus=10431 Good point. Public third-party macros should be AC_DEFUNed for this reason. OK to apply? Yes, please. Done, thanks; but see below. But given the recent thread about AC_DEFUN being able to hoist contents while m4_define does not, would it ever make sense to add a macro in the AC_ namespace that is equivalent to m4_define but still traced by aclocal? Hmm. That would likely require another sister of AU_DEFUN, too, no? Ah, there is another reason to use AC_DEFUN: m4_def(ine|un)'d macros are not upgraded by autoupdate. AFAICS this bit cannot be worked around, as the aclocal bit can by having witness macros. Really I don't think we should advise users away from AC_DEFUN for public macros. This is such an enshrined API, everybody knows that. Changing this usage is likely to take several years. Unfortunately, the name AC_DEFINE is already claimed. Yes. Cheers, Ralf
Re: aclocal problems
By the way, you may be interested in seeing how I was able to use m4_define and still get aclocal to use my file for gnulib's AC_DEFUN_ONCE replacement (coupled with an AC_REQUIRE([gl_00GNULIB]) in gnulib-common.m4): http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/00gnulib.m4 http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=fcf62c3d Yes, I thought this might have been the trick you used: AC_DEFUN a macro with no expansion in the same file, just to get aclocal to include it. Way to work around the rules! :-) Regards, John
aclocal problems
Automake maintainers, On page 158, paragraph 3 of the 2.63 Autoconf manual, it states: If a macro doesn’t use AC_REQUIRE, is expected to never be the object of an AC_REQUIRE directive, and macros required by other macros inside arguments do not need to be expanded before this macro, then use m4_define. So the Autoconf manual is encouraging users to use m4_define, however, when I define a macro using m4_define in a .m4 file in the m4 directory of my project, aclocal ignores it by not m4_including it in the generated aclocal.m4 file. It appears to require the use of AC_DEFUN, rather than m4_define in stand-alone .m4 files. Is this a bug in aclocal? I'm using the latest beta version of Automake - 1.10b. Thanks in advance, John
Re: aclocal problems
Hi John, * John Calcote wrote on Fri, Apr 03, 2009 at 09:33:40PM CEST: On page 158, paragraph 3 of the 2.63 Autoconf manual, it states: If a macro doesn’t use AC_REQUIRE, is expected to never be the object of an AC_REQUIRE directive, and macros required by other macros inside arguments do not need to be expanded before this macro, then use m4_define. So the Autoconf manual is encouraging users to use m4_define, however, when I define a macro using m4_define in a .m4 file in the m4 directory of my project, aclocal ignores it by not m4_including it in the generated aclocal.m4 file. It appears to require the use of AC_DEFUN, rather than m4_define in stand-alone .m4 files. Yep. Is this a bug in aclocal? I don't think so. Do you think the quote is an encouragement not to use AC_REQUIRE? For public macros, I'd even venture to say that they should be written so they can be AC_REQUIREd (if they don't take arguments), or at least, that other macros which are expanded inside their contents or their arguments, may themselves AC_REQUIRE yet other macros which are then expanded outside of all this mess. Does the above make sense in any way? Cheers, Ralf
Re: aclocal problems
On 4/3/2009 5:31 PM, Ralf Wildenhues wrote: Hi John, * John Calcote wrote on Fri, Apr 03, 2009 at 09:33:40PM CEST: On page 158, paragraph 3 of the 2.63 Autoconf manual, it states: If a macro doesn’t use AC_REQUIRE, is expected to never be the object of an AC_REQUIRE directive, and macros required by other macros inside arguments do not need to be expanded before this macro, then use m4_define. ... Is this a bug in aclocal? I don't think so. Do you think the quote is an encouragement not to use AC_REQUIRE? For public macros, I'd even venture to say that they should be written so they can be AC_REQUIREd (if they don't take arguments), or at least, that other macros which are expanded inside their contents or their arguments, may themselves AC_REQUIRE yet other macros which are then expanded outside of all this mess. Hmmm. No, I don't think it's an encouragement not to use AC_REQUIRE. It simply states that if you don't use the prerequisite framework, there's no reason to use AC_DEFUN. I supposed that from a certain point of view (a rather sarcastic one), it could be saying something like, if ever you could conceive of a situation in which you wouldn't need to use AC_REQUIRE, then go ahead and use m4_define. I agree completely with your assessment, but I think the manual should make it clear that the only proper way to write a macro is with AC_DEFUN, don't you? I mean, if the only way I can write a macro outside of adding it directly to configure.ac (which is pointless in all but the strangest cases) is to use AC_DEFUN, then *when* would I ever be able to successfully use m4_define? I suppose it might work in acsite.m4, as that's not included by aclocal.m4. My only point is that the manual is a bit unclear on this point - almost misleading, in fact. I'd call it a documentation bug at this point. (Eric - comments?) Regards, John
