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: 29 Nov 2000 11:24:16 +0100
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

>>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:

Alexandre> On Nov 28, 2000, Akim Demaille <address@hidden> wrote:
Pavel> I don't want to force any style (i.e. creating sub-macros),
Pavel> unless I have a good excuse.

>> I want to force the Autoconf style.

Alexandre> I agree with Pavel.  It's ok if we rule that any code that
Alexandre> goes into autoconf should follow certain guidelines, but we
Alexandre> shouldn't force this upon our users.  

When it comes to exposing the internals of Autoconf in order to
support different coding styles, I disagree.


Alexandre> It's just like if tomorrow someone decided that GCC would
Alexandre> no longer compile code that uses variable names that start
Alexandre> with upper case, or that don't have a line break before
Alexandre> `{'.

Autoconf is not a language, it's a library.  I'm not in favor of
AC_LANG_CASE because (i) I don't think people need it, (ii) if some
people *really* need something along these lines, then what they
really need is the dispatching scheme.


Alexandre> I think AC_LANG_CASE is a good thing, as long as the
Alexandre> default case produces an error message stating that the
Alexandre> current language <FOO> is not supported by macro <BAR>.

I'm ready to be convinced, but currently I can see no use for this to
be exposed to users.  The points where such details are needed is
really in the core Autoconf.

I'm not in favor of documenting it also because it pushes people to do
things which they shouldn't.  The guile example is quite typical: they
were actually recoding some version of AC_CHECK_FUNC, so they started
from 2.13 and discovered there were no macro suited to their needs.
Now there are: AC_LANG_SOURCE etc.  That's the only reason why they
needed AC_LANG_CASE.  Now they don't.

dnl This is needed when we want to check for the same function repeatedly
dnl with other parameters, such as libraries, varying.
dnl
dnl GUILE_NAMED_CHECK_FUNC(FUNCTION, TESTNAME,
dnl                        [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
AC_DEFUN(GUILE_NAMED_CHECK_FUNC,
[AC_MSG_CHECKING([for $1])
AC_CACHE_VAL(ac_cv_func_$1_$2,
[AC_TRY_LINK(
dnl Don't include <ctype.h> because on OSF/1 3.0 it includes <sys/types.h>
dnl which includes <sys/select.h> which contains a prototype for
dnl select.  Similarly for bzero.
[/* 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
], eval "ac_cv_func_$1_$2=yes", eval "ac_cv_func_$1_$2=no")])
if eval "test \"`echo '$ac_cv_func_'$1'_'$2`\" = yes"; then
  AC_MSG_RESULT(yes)
  ifelse([$3], , :, [$3])
else
  AC_MSG_RESULT(no)
ifelse([$4], , , [$4
])dnl
fi
])

now becomes

AC_DEFUN([GUILE_NAMED_CHECK_FUNC],
[AC_VAR_PUSHDEF([ac_var], [ac_cv_func_$1_$2])dnl
AC_CACHE_CHECK([for $1], ac_var,
[AC_LINK_IFELSE([AC_LANG_FUNC_LINK_TRY([$1])],
                [AC_VAR_SET(ac_var, yes)],
                [AC_VAR_SET(ac_var, no)])])
AS_IFELSE([test AC_VAR_GET(ac_var) = yes],
          [$2], [$3])dnl
AC_VAR_POPDEF([ac_var])dnl
])# AC_CHECK_FUNC

and now, for free, it works for any other language.



reply via email to

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