autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documenting AC_LANG_CASE


From: Akim Demaille
Subject: Re: Documenting AC_LANG_CASE
Date: 28 Nov 2000 18:02:22 +0100
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

>>>>> "Pavel" == Pavel Roskin <address@hidden> writes:

Pavel> Hello, Akim!  Sorry for the late reply.

no problem, I myself, have rather big delays...  Sorry I don't pay
more attention to Autoconf.


Pavel> There is no such macros as AC_LANG_DISPATCH. There is
Pavel> _AC_LANG_DISPATCH, which is a private macro. We can rename it,
Pavel> of course, or create a fool-proof wrapper around
Pavel> _AC_LANG_DISPATCH.

Yes, sorry.

Pavel> My primary concern is that some very specialized macros that
Pavel> are currently C-only may need minor changes for C++. Forcing
Pavel> AC_LANG_DISPATCH will mean that the variable part of the macro
Pavel> will have to be separated into a different macro.

Pavel> My feeling is that AC_LANG_CASE is more user-friendly.

I agree.  I just doubt the user needs something like this.  This is
why I believe such needs for dispatching macros shall be handled at
the level of Autoconf.  This is why I'm not in favor of documenting
any such macro until someone shows a real need for it.

Pavel> I don't want to force any style (i.e. creating sub-macros),
Pavel> unless I have a good excuse.

I want to force the Autoconf style.  Much of the past complexity and
today's residual complexity in Autoconf comes from the fact that there
was no strict coding style, no guideline, no structure at all, not
even basic layers.

Today, there are separate layers (and I'm not just referring to
M4sugar and M4sh), Autoconf is much more modular, and I'm working at
keeping it as pure as it can be: that's its only way out.  Autoconf
needs rigor to be maintainable and open to extensions.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]