Re: justification for AC_LANG_ASSERT?

[Akim Demaille]

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

Not if you consider that this is only the beginning.  We have to start
somewhere, and the fact that there are two flavors of Fortran
emphasizes that need.

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

We are referring to two sets of confusion.  One was mine, believing
the right thing happened.  The other, due to AC_LANG_ASSERT ends with
an explicit error message.  I believe the latter is saner.

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

Yes, but again, some dummies ---such as me---, will really believe FC
is polymorphic wrt the Fortran flavor.


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

You seem to imply I claim we should wrap AC_FC_FREEFORM only.  Nope:
we ought to wrap the _whole Fortran section_ with AC_LANG_PUSH/POP.
I'm not saying a proper configure.ac is

| AC_INIT
| # No Fortran compiler is known not to support "*.f".
| AC_PROG_FC
| AC_LANG_PUSH(Fortran)
| AC_FC_SRCEXT([f])
| AC_LANG_POP(Fortran)
| 
| # GNU Fortran is known to support freeform.
| AC_LANG_PUSH(Fortran)
| AC_FC_FREEFORM([],
|                [AC_MSG_WARN([Fortran does not accept free-form source])])
| AC_LANG_POP(Fortran)
 
I'm saying it should be:

  AC_INIT

+ AC_LANG(Fortran)
  AC_LANG_COMPILER
  
  # No Fortran compiler is known not to support "*.f".
  AC_FC_SRCEXT([f])
  
  AC_FC_FREEFORM([],
                 [AC_MSG_WARN([Fortran does not accept free-form source])])



configure.ac with language dependent sections should wrap the whole
section.  Continuing to pretend that Autoconf is context-free wrt
language is wrong a message to send to users.