On Sat, 15 Nov 2003, 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. But it's even more confusing to use *both* idioms, with the AC_LANG_PUSH idiom used for only *two* macros out of all autoconf. > If you are sure that my mistake is an isolated case, and that noone, ever, > will be lost in some obscure combination of FC vs. F77, then OK, we can > revert. But even in such a case (I'm the only loser), this is bad IMHO. Akim, you're forgetting that there are downsides to the current choice, too. I honestly think that far more people will be confused by an AC_PUSH requirement that applies to only two macros in autoconf, compared to the (I think, small) number of people who will be confused by those macros behaving like the *rest* of autoconf's language-specific macros: macro name indicates language. > danger for C, C++ etc. I guess, but Fortran, hiding being a single > name two different sets, is much more exposed to such problem. Except it's not one name, it's two: FC and F77. Unless the macro itself is polymorphic with the current language choice, we're only arguing about syntax, not semantics. The only difference between my proposal (just call AC_FC_FREEFORM) and yours (AC_LANG_PUSH(Fortran); AC_FC_FREEFORM; AC_LANG_POP(Fortran)) is how much verbiage is required to convey the same semantic content. Steven
