autoconf-patches
[Top][All Lists]
Advanced

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

Re: Fortran 9x support


From: Steven G. Johnson
Subject: Re: Fortran 9x support
Date: Tue, 12 Nov 2002 13:40:34 -0500 (EST)

On 12 Nov 2002, Akim Demaille wrote:
> | 4) I've added two new FC-only macros specifically for newer Fortran
> | dialects.  For a complete description, see the source, but to summarize:
> | 
> | AC_FC_SRCEXT(EXT, [ACTION-IF-SUCCESS], [ACTION-IF-FAIL])
> |     -- set the extension used for subsequent tests to EXT (e.g. f90);
> | the default extension is f.  Also can detect whether special compiler
> | flags are required to support the new extension (in particular with IBM's
> | compilers).
> 
> The name is quite cryptic, why not AC_FORTRAN_SRCEXT?  Actually,
> should this be hidden into some
> 
> AC_LANG_SRCEXT
> 
> which would set $ac_$lang_srcext to one or several supported
> extensions?  I mean, do we want to expose the low level macro
> AC_FC_SRCEXT?

Are there any other languages for which the choice of extension makes a
difference in how code is compiled?  It seems like an annoying kludge for
Fortran 9x to me.

(The name was to indicate that it is specific to FC, not F77.  Perhaps
AC_PROG_FC_SRCEXT?  But you'll already have a bunch of AC_FC_* macros in
parallel with AC_F77_*, so I should think it would be clear.)

> I tend to think that we might want more languages.  Why not
> 
> AC_LANG(Preprocessed Fortran)

(Handling preprocessed Fortran is a tricky issue and one which I don't
want to address at this time.  But I'm inclined to think it wouldn't
require another language per se, just a macro to find a preprocessor
and/or to see whether .F* is supported for preprocessing.)

> vs.
> 
> AC_LANG(Fortran)
> 
> vs.
> 
> AC_LANG(Fortran 2000)

No.  One of the points I tried to address in my rationale (posted to
address@hidden) is that (to summarize):

(a) The F77 macros are for legacy code, and are not really how we want to
treat Fortran going forward.  We really don't want a separate set of
environment variables, macros, etcetera for every revision of the Fortran
standard, any more than we do for C or C++.  It's just a mess, for both us
and for users.

(b) You need to be able to compile both Fortran 9x and Fortran 77
separately, because the latter are often legacy codes and F77 is
practically a completely different language.  On the other hand, people
are unlikely to need to mix newer Fortran dialects (or if they do, they
can edit the source to remove the small incompatibilities and compile
everything under the latest dialect, just like they do for C or C++).

> We should drop AC_PROG_FOO for compilers and such, they are too
> special.

Well, you have AC_LANG_COMPILER if you want to encourage users to employ
that.  You will always need some language-specific macros at the back end,
however, whether or not you want to expose them.  And there will always be
language-specific user-exposed macros like AC_{F77,FC}_WRAPPERS.

In any case, getting rid of language-specific macros would be a
significant departure from the current style of autoconf, and I'm not sure
this patch is the best place for it.

Steven





reply via email to

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