Re: Documenting AC_LANG_CASE

[Akim Demaille]

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

Thanks!  But I'd still like to know what this macro does.  What's the
full code?

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

Right, and it is on purpose since we want to maximize the chances to
have ./configure CC=g++ work properly.

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

Thanks!