autoconf-patches
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]