Re: justification for AC_LANG_ASSERT?

[Akim Demaille]

 > Akim Demaille wrote:
 >> Nope, indeed, that's why it's too late to change the others.  But, IMHO,
 >> this interface is merely the unfortunate result of history, where
 >> Autoconf was not designed from scratch to support several languages.
 >> That's also why I would much better enforce the
 >> AC_LANG_PUSH/AC_LANG_COMPILER idiom than AC_PROG_WHAT'S_THE_NAME_OF_THE
 >> _COMPILER_AGAIN.

 > Honestly, I'm not convinced that AC_LANG_PUSH/AC_COMPILER is a better
 > idiom than having the language specified per-macro via the macro
 > name. In the AC_LANG_PUSH scenario, the meaning of AC_COMPILER
 > etcetera depends upon a global state that is set elsewhere, i.e. is
 > invisible at the time the AC_COMPILER macro is called.  The history of
 > computer science suggests that having the meaning of a function change
 > drastically as a side-effect of an earlier function call is not a
 > recipe for clarity.

Right.  The day we have OOAutoconf, then we can write

$lang.AC_COMPILER_CHECK
$lang.AC_CHECK_FUNC(fnmatch)

but as of today, this is addressed via a hidden global.  Pretending it
is not there seems even worse to me.


 >> This scheme already shows its limitations with Fortran.  If we had followed
 >> only the AC_LANG_* scheme, there would not have been such confusion.

 > Remember, the main trick for Fortran was not a question of specifying
 > the language (which could have been done already just by passing the a
 > different list of compilers to AC_PROG_F77), but the fact that you
 > really need two sets of output variables so that F77 and modern
 > Fortran can be used simultaneously in the same Makefile.

 > (And, as I said in another message, for new macros like AC_FC_FREEFORM
 > that correspond to new features of modern Fortran only, the
 > polymorphism implied by AC_LANG_PUSH is not useful.)

It's worse than this: today being an educated user of Autoconf is
still too much of a job for a regular maintainer.  The sheer number of
the macros is a demonstration of one of the failures of Autoconf.
I'll continue to strive against the addition of new macro(-names) when
overloading can do it.

Now that I have seen again how the FC implementation is done, I'll
struggle to go back to what I first asked.  For instance:


   # _AC_PROG_FC_C_O
   # ---------------
   AC_DEFUN([_AC_PROG_FC_C_O],
   [....
   ])# _AC_PROG_FC_C_O
   
   
   # AC_PROG_F77_C_O
   # ---------------
   AC_DEFUN([AC_PROG_F77_C_O],
   [AC_REQUIRE([AC_PROG_F77])dnl
   AC_LANG_PUSH(Fortran 77)dnl
   _AC_PROG_FC_C_O
   AC_LANG_POP(Fortran 77)dnl
   ])# AC_PROG_F77_C_O
   
   
   # AC_PROG_FC_C_O
   # ---------------
   AC_DEFUN([AC_PROG_FC_C_O],
   [AC_REQUIRE([AC_PROG_FC])dnl
   AC_LANG_PUSH(Fortran)dnl
   _AC_PROG_FC_C_O
   AC_LANG_POP(Fortran)dnl
   ])# AC_PROG_FC_C_O


should become


   # AC_PROG_FC_C_O
   # ---------------
   AC_DEFUN([AC_PROG_FC_C_O],
   [....
    AC_LANG_COMPILER_REQUIRE
   ])# AC_PROG_FC_C_O
(this is what was _AC_PROG_FC_C_O).

   
   # AC_PROG_F77_C_O
   # ---------------
   AC_DEFUN([AC_PROG_F77_C_O],
   [AC_LANG_PUSH(Fortran 77)dnl
    AC_PROG_FC_C_O
    AC_LANG_POP(Fortran 77)dnl
   ])# AC_PROG_F77_C_O

The mess wrt variables (FC vs. F77 etc.) needs special treatment,
agreed.  But, for a start, do we really have projects cumulating both
flavors?  And if so, how come we didn't care about those mixing
Fortran 95 vs. say Fortran 2000?