[Top][All Lists]
[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: |
24 Nov 2000 10:37:00 +0100 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) |
| Index: doc/autoconf.texi
| --- doc/autoconf.texi Fri Nov 17 12:27:15 2000
| +++ doc/autoconf.texi Thu Nov 23 17:04:06 2000
| @@ -4409,7 +4409,7 @@
| check for characteristics not listed here, use @code{AC_TRY_COMPILE}
| (@pxref{Examining Syntax}) or @code{AC_TRY_RUN} (@pxref{Run Time}),
| making sure to first set the current language to Fortran 77
| address@hidden (@pxref{Language Choice}).
| address@hidden(Fortran 77)} (@pxref{Language Choice}).
|
| @defmac AC_F77_LIBRARY_LDFLAGS
| @maindex F77_LIBRARY_LDFLAGS
Good.
| @@ -6038,10 +6038,12 @@
| @section Language Choice
| @cindex Language
|
| -Packages that use both C and C++ need to test features of both
| -compilers. Autoconf-generated @code{configure} scripts check for C
| -features by default. The following macros determine which language's
| -compiler is used in tests that follow in @file{configure.in}.
| +Autoconf-generated @code{configure} scripts check for the C compiler and
| +its features by default. Packages that use other programming languages
| +(maybe more than one, e.g. C and C++) need to test features of the
| +compilers for the respective languages. The following macros determine
| +which programming language is used in the subsequent tests in
| address@hidden
|
| @defmac AC_LANG (@var{language})
| Do compilation tests using the compiler, preprocessor and file
This is good too.
| @@ -6075,6 +6077,15 @@
| @maindex LANG_POP
| Select the language that is saved on the top of the stack, as set by
| @code{AC_LANG_PUSH}, and remove it from the stack.
| address@hidden defmac
| +
| +Following macros make it possible to write tests for many languages:
| +
| address@hidden AC_LANG_CASE (@var{language1}, @var{if-language1},
@ovar{language2}, @ovar{if-language2}, @dots{})
| address@hidden LANG_CASE
| +If @var{language1} is currently used, expand to @var{if-language1},
| +otherwise if @var{language2} is currently used, expand to
| address@hidden and so on.
| @end defmac
|
| @defmac AC_REQUIRE_CPP
I don't think we should document AC_LANG_CASE, and in fact I tend to
think we should get rid of it (Autoconf does not use it). I made it
because at first it seemed to be a good idea, but it's a stupid one:
AC_LANG_DISPATCH is the right interface. The most important
difference being that AC_LANG_CASE is closed, while AC_LANG_DISPATCH
is open: code using the former is necessarily obsolete as soon as you
(or the user) add a new language, while not the latter.
Do you think about a particular case where this would be useful?
- Documenting AC_LANG_CASE, Pavel Roskin, 2000/11/23
- Re: Documenting AC_LANG_CASE,
Akim Demaille <=
- Re: Documenting AC_LANG_CASE, Pavel Roskin, 2000/11/28
- Re: Documenting AC_LANG_CASE, Alexandre Oliva, 2000/11/28
- Re: Documenting AC_LANG_CASE, Akim Demaille, 2000/11/29
- Re: Documenting AC_LANG_CASE, Alexandre Oliva, 2000/11/29
- Re: Documenting AC_LANG_CASE, Akim Demaille, 2000/11/29
- Re: Documenting AC_LANG_CASE, Alexandre Oliva, 2000/11/29
- Re: Documenting AC_LANG_CASE, Akim Demaille, 2000/11/29