Re: 01-ac-lang-compiler-require.patch (Was: CC/CPP/TRY_LINK)

[Pavel Roskin]

Hello, Akim!

> | By the way, shouldn't we change the syntax of AC_LANG to
> | 
> | AC_LANG(C, COMPILERS, ACTION-IF-FOUND, ACTION-IF-NOT-FOUND)
> | 
> | and go ahead if no C compiler has been found but ACTION-IF-NOT-FOUND is
> | given?
> 
> What advantage would that bring?  How do you deal with the implicit
> initial AC_LANG(C).  AC_LANG is here to select the current language,
> its semantics should not be overloaded IMHO.

I just wanted to give you a hint. I'm not going to defend it very
strongly, but let me enumerate the advantages.

1) Whenever you switch the language you have all the needed tools
(compiler, preprocessor) tested for that language.

2) You can allow C to be used implictly, you just cannot specify the
compiler and ACTION-IF-NOT-FOUND if you omit AC_LANG.

3) AC_LANG is already overloaded. AC_LANG without arguments used to expand
to the language name, but now it's broken.

I'm almost sure that the new AC_LANG should be implemented after 2.50, but
I just wanted to explain you my vision of the future development, since
you are going to touch that stuff soon.

> | I really hate all those "exit 77" in the autoconf code - it's an attempt
> | to accomodate the testsuite at the expence of the users.
> 
> Errr, what's the problem with exit 77 instead of exit 1?

1) Both lack any clean mechanism for traping them in configure.in. Several
packages, including Ncurses, use C++ optionally. Common workarounds are
redefining AC_MSG_ERROR and surrounding AC_PROG_CXX by parentheses. I
don't like either of them.

2) "exit 77" is used in other testsuites, not only in Autoconf. This is
probably not a very strong argument, but why should Autoconf decide what
other testsuites should ignore?

Regards,
Pavel Roskin