Re: Documenting AC_LANG_CASE

[Pavel Roskin]

> 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.

I looked me carefully at that macro. Here's a bigger chunk:

[/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char $1(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
]ifelse(AC_LANG, CPLUSPLUS, [#ifdef __cplusplus
extern "C"
#endif
])dnl
[/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char $1();
], [
/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_$1) || defined (__stub___$1)
choke me
#else
$1();
#endif
]

Checking the current language is pointless. "#ifdef __cplusplus" is
harmless in the C code. The only price is few extra lines in "configure"
for C projects. Autoconf itself doesn't eliminate them.

So I'm going to apply my changes to the documentation with the exception
of AC_LANG_CASE that should remain undocumented.

Regards,
Pavel Roskin