Re: Documenting AC_LANG_CASE

[Alexandre Oliva]

On Nov 29, 2000, Akim Demaille <address@hidden> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:
Alexandre> On Nov 29, 2000, Akim Demaille <address@hidden> wrote:
>>> Now there are: AC_LANG_SOURCE etc.  That's the only reason why they
>>> needed AC_LANG_CASE.

Alexandre> I see.  With AC_LANG_SOURCE, it's easy enough to construct
Alexandre> AC_LANG_CASE out of nested ifs.  

> :) :) :)

I take it back.  I had read that as the former argument-less AC_LANG,
that would expand to the current language name.

Alexandre> But then, why not provide it in the first place?

> My point is that AC_LANG_CASE is extremely low level

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

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

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

> More seriously, what did you mean with ``With AC_LANG_SOURCE, it's
> easy enough to construct AC_LANG_CASE out of nested ifs''?

I meant I was tired, sleepy and confused.  In fact, I'm still tired
and sleepy, but I don't feel that confused anymore :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me