Re: ac-lang-compiler-gnu.patch

[Akim Demaille]

| > Index: ChangeLog
| > from  Akim Demaille  <address@hidden>
| >     * aclang.m4 (_AC_LANG_COMPILER_GNU): New macro, which unifies...
| >     (_AC_PROG_F77_GNU, _AC_PROG_CC_GNU, _AC_PROG_CXX_GNU): Remove.
| >     Adjust dependencies.
| 
| Ok provided that
| 1) The testsuite passes (my favourite condition :-))

The patch I submit are *always* tested.

| 2) You read my comments and make adjustments when needed.

Well, of course!


| > -[if test "ac_gnu_compiler" = yes; then
| > +[if test "$ac_compiler_gnu" = yes; then
| 
| Missing "$" must be a typo. If it is please apply it separately.

Yes it is.  But if my patch applies, I can't find any interested in
submitting two changes.  But OK, I will.


| > -ac_gnu_compiler=$ac_cv_prog_gcc
| > +ac_compiler_gnu=$ac_[]_AC_LANG_ABBREV[]_cv_compiler_gnu
| 
| Could you please avoid such renamings?

I'd like to avoid avoiding renamings for it makes the syntax cleaner.

| I can imagine many configure.in's using it e.g. to add -Wall to CFLAGS.

This is *bad*.  But I hear your call.  Consider my patch comes with

AU_ALIAS(ac_cv_prog_gcc, ac_c_cv_compiler_gnu)

(plus the quotes, of course ;)


| > +[_AC_COMPILE_IFELSE([AC_LANG_SOURCE([[#ifndef __GNUC__
| > +  choke me
| > +#endif
| 
| How about that semicolon - shouldn't we still worry about NeXT:
| 
| > -[# The semicolon is to pacify NeXT's syntax-checking cpp.
| > -cat >conftest.$ac_ext <<_ACEOF
| > -#ifdef __GNUC__
| > -  yes;
| > -#endif

Nope, I don't think so, precisely because I reversed the ifdef.  See
also AC_LANG_FUNC_LINK_TRY(C).


| > -if test $ac_cv_prog_gcc = yes; then
| > +if test $ac_c_cv_compiler_gnu = yes; then
| 
| Please, leave those names alone! You can just define them like
| _AC_LANG_ABBREV for every language.

Gross, gross, and gross!



| I'm sure a lot of code depends on the traditional names.
| 
| > -#ifdef __GNUC__
| > -  yes;
| > -#endif
| 
| Note this semicolon again for C++ - there must be a reason.

Yes, the reason is that, as the comment states it, cpp on NeXT behaves
like the parser of a compiler, hence you need at least syntactic
conformance to the input language.  But here it doesn't apply since I
reversed the cpp directive.

        Akim