autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: justification for AC_LANG_ASSERT?


From: Akim Demaille
Subject: Re: justification for AC_LANG_ASSERT?
Date: Sat, 15 Nov 2003 09:20:21 +0100 (CET)

Steven G. Johnson a dit:

> On Fri, 14 Nov 2003, Akim Demaille wrote:
>> Steven, you don't seem to read my messages in another thread,
>> precisely related to this:
>>
>> http://mail.gnu.org/archive/html/autoconf-patches/2003-10/msg00116.html
>
> Akim, the only justification you give there is that you had called an
> AC_FC macro in a file that you wanted to just be testing Fortran 77.  But
> if you want to catch that sort of "error", you need to put asserts in
> essentially every macro (from AC_PROG_CC onwards...), which I don't think
> anyone would thank you for.

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.

This scheme already shows its limitations with Fortran.  If we had followed
only the AC_LANG_* scheme, there would not have been such confusion.

> If the name of the macro contains F77/FC/CC/C/CXX, I should think that is
> enough of a clue to the user, in general, that it applies to a particular
> language.  The additional "error" checking of puting a language assert, in
> my opinion, doesn't outweigh the incredible inconvenience of forcing the
> user to call push/pop when it is completely superfluous.

I beg to differ: I honestly believed my test case, i.e., my micro
configure.ac, was OK: checking for some features of the F77 compilers.
It turned out that it was doing something completely different: checking
features for a compiler I had not even checked for myself.

I've been bitten.

> Put another way, we have to assume that if the user calls a macro, then
> that is the macro they want.  Otherwise, we might as well add new macros
>
> AC_I_REALLY_MEAN_TO_CALL_THIS([AC_FOO])
> AC_FOO
> AC_OK_I_AM_DONE_WITH_THIS([AC_FOO])

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.

Autoconf is highly contextual wrt languages.  It is a very bad legacy
habit to have the compiler etc. checks escape this context.  That's
why I'm pushing for AC_LANG_COMPILER and so forth.  There is not much
danger for C, C++ etc. I guess, but Fortran, hiding being a single
name two different sets, is much more exposed to such problem.

If the problem is a lack of documentation wrt AC_LANG_COMPILER etc., then,
yes, it is time that I fix this.  But let's not revert this AC_LANG_ASSERT
change, it is going forward.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]