Re: Fortran 9x: time for a decision

[Andreas Buening]

Steven G. Johnson wrote:
> 
> With each year that goes by, the need to address this issue in autoconf
> and automake increases.  We need to make a decision, especially since
> people keep submitting patches with conflicting strategies for this issue.
> 
> Kate Hedstrom wrote:
> > It seems to me that the compiler name of $F77 is unfortunate in that it
> > cries out for $F90 and $F95 friends. Some versions of make use $FC
> > instead - can we change the $F77? Ignoring that everything is called f77,
> > I could use fortran.m4 as it stands if the compiler search were reversed,
> > with f95 first and f77 last. Bill Wendling's module check is a useful
> > addition, as is the f95 forall check.
> 
> Every time this issue comes up, there are various people who come out of
> the woodwork to say that they need to compile both Fortran 77 and F9x in
> the same project, where the former are legacy codes written in ways
> incompatible with the newer standards.

It looks like I'm also one of those people and I've to come out of
the woodwork. ;-)


> On the other hand, it is completely crazy to have a new F?? for every
> revision of the Fortran standard.  Moreover, the newer revisions seem to
> be much more compatible with one another, so that most(?) F90 codes will
> compile under F95, etcetera, and more importantly they seem less likely
> to be mixed in a single project.

Most likely.


> I've been thinking about this, and my suggestion is:
> 
> 1) Have two compilers, F77 and FXX, where the former tries to be F77
> (i.e. the current behavior) while the latter is selected by
> AC_PROG_FXX([year], [search-list]), where year is YY or YYYY with YY <
> 54 interpreted as 20YY, and with the default year being the latest
> supported Fortran standard.  Unknown years trigger an error.  (Have
> $FXXFLAGS etc. in analogue to $FFLAGS etc.)  Rationales:

[snip]

It would be nice to be able to compile f90 programs with autoconf.
If you can implement this, please, feel free to do it.

I can't tell about "general fortran projects" but I can tell you
about the project I have to use for my work. It uses f90 code I've
written mostly myself, f77 legacy code for the program "core" that
is incompatible with any f9x compiler and some C code for system tasks.
I'd like to use autoconf for it but I don't think it'll be possible with
the current autoconf design.

It's not just the problem that you have to find two different
compilers, one for the f77, one for the f9x source files, it's
also the problem to find the compiler options you need.
With C it's not a real problem. On most systems "-g -O2" will work
and "-O2 -s" will be fine. But with Fortran it's much more difficult.
You may have some f77 files that have to be preprocessed (e.g. ".F"
file extension), you may have also some f77 files that have NOT
to be preprocessed (due to compiler bugs; I have this problem).
You may have f90 files in free format, others in fixed format
but you have just a few file extensions (.f, .F, .f90, .F90) to signal
which file has to be handled which way. You may specify this behaviour
in AC_PROG_FXX.

Some compilers may not recognize several file extension or may have
a hardcoded default which file extension implies which dialect/source
format. So you may have to find out the compiler option to tell the
compiler that .f90 is a f90 file and not an object file.

You may have to find out which options turns the preprocessor on/off
and how you can forward macros to the preprocessor, not every compiler
supports -D__FOO__. Maybe the compiler supports different preprocessors
but just one of them is installed.

You may have to find out how to switch between fixed format and
free source format.

For some compilers -I/some/dir might not be sufficient to find "include"
files.

You may need special options for code that is not standard compliant,
e.g. to tell the compiler that a declaration real(4) means that this
variable really has a size of 4 bytes. If you compile that code on
a 64 bit cpu you might have to tell the compiler to use 32 bit integers.

But it's even worse. It's not that AC_PROG_F77 and AC_PROG_FXX
are independent of each other. If you find a f9x compiler of a specific
vendor you have to use also the f77 compiler of the same vendor.
E.g. you can't link files compiled with g77 and f95n (NAGWare)
because both rely on their own internal library and both don't know
of each other.

At the end you have the problem that only the maintainer knows which
features he needs and only the user (if at all) knows which compiler
options provide which feature on his system.
If the maintainer wants to have a portable installation mechanism
he has to write a script (or at least a database) which system
and which compiler requires which set of options for which kind of
source file and which compiler. But that's completely opposite to
the autoconf philosophy to write one generic configure.ac and
every user can specify his extra options if he wants.

Just my 2 cents.


Bye,
Andreas