On Thu, 20 Nov 2003, Akim Demaille wrote: > Right. The day we have OOAutoconf, then we can write > > $lang.AC_COMPILER_CHECK > $lang.AC_CHECK_FUNC(fnmatch) But <lang>.AC_COMPILER_CHECK is just an alternate spelling of AC_<LANG>_COMPILER_CHECK or AC_PROG_<LANG>. You are proposing and criticizing the same thing! > but as of today, this is addressed via a hidden global. Pretending it > is not there seems even worse to me. But it *isn't* addressed via a hidden global for AC_<LANG>_FOO macros; these have exactly the semantics of <lang>.AC_FOO that you propose above. AC_CHECK_FUNC et al. are a different matter. > # 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). So, instead of having AC_PROG_FC_C_O (current), you are recommending: AC_LANG_PUSH(Fortran) AC_PROG_FC_C_O AC_LANG_POP(Fortran) How is this better? This is just a different (and more verbose) spelling. Rather, I would suggest the following: 1) If you like the AC_PUSH style, encourage users to use it with the generic AC_LANG_COMPILER, possibly writing new language-dispatched macros like AC_LANG_COMPILER_C_O for generic-enough features. Do this for *all* languages; doing it for just a few macros of one language is worse than for none at all. 2) Keep the current AC_PROG_<LANG> style macros for people still using the "old style". 3) For macros that truly are specific to a particular language, like AC_FC_FREEFORM, keep them the way they are. This has the right semantics, since AC_<LANG>_FOO is an alternate spelling of <LANG>.AC_FOO, and the language-specific AC_<LANG>_FOO is a natural syntactic parallel to the language-generic AC_LANG_FOO. 4) Ditch AC_LANG_ASSERT(<LANG>), because it is redunant for a language-specific AC_<LANG>_FOO macro (an inapplicable to generic AC_LANG_FOO macros). > The mess wrt variables (FC vs. F77 etc.) needs special treatment, > agreed. But, for a start, do we really have projects cumulating both > flavors? Yes. I do it myself, and other people came out about this every time we debated it on the mailing list. There are 30 years of legacy F77 code out there that people aren't willing to touch, and bringing it up-to-date with the latest standards is a major effort. > And if so, how come we didn't care about those mixing Fortran 95 vs. > say Fortran 2000? Because Fortran 95 and Fortran 2000 are basically compatible with one another (and are close in time so that the people writing the codes didn't die decades ago), whereas F77 is essentially a different language. It makes sense to treat it, *going forward*, like C and C++, where we don't have different macros for different versions of the language. We just expect people writing C code to maintain their code so that it is at least compatible with the latest standard (not hard to do), and to test feature-by-feature for new features if necessary. Steven
