Re: Documenting AC_LANG_CASE

[Akim Demaille]

>>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:

>> My point is that AC_LANG_CASE is extremely low level

Alexandre> Lower level than creating a couple of dispatch functions?
Alexandre> I must disagree.  Vehemently! :-)

Nope, LANG dispatching *and* casing macros are low level as opposed to
macros which are built atop.

Alexandre> Think of someone writing a macro whose test only makes
Alexandre> sense for, say, Java, and s/he wants to make sure the
Alexandre> current language is Java and just abort `autoconf/m4'
Alexandre> otherwise.  AC_LANG_CASE is exactly what he needs.  How
Alexandre> would he accomplish the same within the
Alexandre> language-dispatching framework?

This, I very much agree!  We need something like AC_LANG_ASSERT.  I
wholeheartedly agree!  There are plenty of AC_LANG() in Autoconf which
should be AC_LANG_ASSERT.

But without this, the normal behavior is to AC_LANG_PUSH(Java) in the
beginning of the macro, and pop it at the end.

Alexandre> Forcing the person to create a new macro, say
Alexandre> `IS_LANG_JAVA(JAVA)', that would do nothing, then using
Alexandre> _AC_LANG_DISPATCH (which isn't part of the public
Alexandre> interface) to make sure the current language is JAVA
Alexandre> (because IS_LANG_JAVA(otherlang) is supposed to not be
Alexandre> defined, so _AC_LANG_DISPATCH would complain) is *far* too
Alexandre> cumbersome.

Right, but the problem is then that Autoconf does not provide enough
medium level macros.  And we will have to face it, and cure Autoconf.
At the same time we shall provide the user with what it needs to
continue her work, i.e., the code to support her needs.