Re: Fortran 9x: time for a decision

[Steven G. Johnson]

On Tue, 29 Oct 2002, Andreas Buening wrote:
> 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.

Portable preprocessed Fortran is indeed an important (and tricky)
question, but one which (I think) is a separate problem from the present
one of just finding a Fortran compiler, etcetera.

Regarding the inference of dialect from file ending, I thought the main
problem would be that if you use .f the compiler might interpret it as
fixed-format...which is "solved" by using .f for legacy code (F77) and
.f90 or whatever for newer code.  Is there any F90+ compiler that doesn't
interpret .f90 as F90 source??

The general problem of finding a flag to force free-format/fixed-format
interpretation is an issue for another macro, I think.

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

I know.  This problem already exists in the present autoconf, because
you may want to link with Fortran libraries that are compiled with
different compilers, etcetera.

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

Ultimately, this sort of thing has to be handled by custom macros, if the
maintainer needs particular nonstandard language features.  Particularly
common needs might go into the macro repository and from there (maybe)
make their way into the standard autoconf.

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

Not necessarily.  You can try compiling a small test program exhibiting
the feature you want, looping through the possible flags from different
systems/compilers until one works.  This is how AC_PROG_CC_STDC works, for
example.

Steven