Re: Fortran 9x: time for a decision

[Andreas Buening]

Steven G. Johnson wrote:
> 
> 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.

Not really. If you have preprocessed Fortran files then "finding a
compiler" means "finding a compiler with preprocessing". Otherwise
that compiler is useless (and you should proceed with your search).


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

xlf90, IBM's compiler for AIX. It requires -qsuffix=f=f90.

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

This means you need a "database", one different flag for every compiler.


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

The basic idea is that you use the "default" system compiler that
has (hopefully) been used to compile all those system libraries. ;-)


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

In other words: You need a "database".


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

Some compilers (like f95n) try to find out the source file format
(fixed/free) themselves. For a "print *, 'hello, world'" test program
this might work correctly but for a more complicated source file
it might fail. In this case there is no possibility for autoconf to find
out whether that compiler can really handle fixed/free format.


Bye,
Andreas