Akim Demaille wrote:
I saw that you have wrapped many macros with AC_LANG_PUSH/POP. I
don't think this is the right thing to do. Rather, you should require
from the user to call these macros with the right current language. I
have appended some notes about this in the documentation.
[...] Index: ChangeLog
from Akim Demaille <akim@xxxxxxxx>
* tests/fortran.at (GNU Fortran 77): Don't run FC macros. (GNU Fortran): New. * doc/autoconf.texi (Language Choice): Document. * lib/autoconf/fortran.m4 (AC_FC_SRCEXT, AC_FC_FREEFORM): Assert the current language is Fortran.
I just got an email from a user complaining about this, that
AC_PROG_FC(f90) AC_FC_SRCEXT(f90)
no longer works in his configure.ac, and on reflection I'm questioning the decision to use AC_LANG_ASSERT, and indeed its raison d'etre.
What is the point of this macro? Why would someone ever *not* want AC_FC_* to push Fortran itself? Haven't they effectively declared that they want to use Fortran simply by calling the macro...why force them to call two additional macros to say that they really mean it?
Can we revert to the previous behavior? (It won't break backwards compatibility, since people still *can* call AC_LANG_PUSH/POP.)
Moreover, why should any macro ever use AC_LANG_ASSERT rather than calling push/pop itself? I don't understand the philosophy here.
Steven
