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