[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: justification for AC_LANG_ASSERT?
From: |
Steven G. Johnson |
Subject: |
Re: justification for AC_LANG_ASSERT? |
Date: |
Sat, 15 Nov 2003 16:12:20 -0500 (EST) |
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