[SciPy-dev] Compiling F77, F90 free, and F90 fixed format codes in scipy_distutils

[Pearu Peterson]

Hi all,

------------------------------------
Background to this message:

Currently some Fortran 90 compiler descriptions in scipy_distutils use
switches that make these compilers to assume that Fortran 90 source codes
are in fixed format. This obviously makes it impossible to compile
Fortran 90 free format sources with these particular compilers.
So, Eric and I have tried to find a solution to this issue in PM. I think
the rest of the story can be extracted from the messages below (sorry if 
some parts are a bit jumpy).
We hope that there are more Fortran 90 users in this list who may
have some additional comments/ideas how to resolve this issue.

Basically, the key question is how to decide if a Fortran source file
contains Fortran 77, Fortran 90 free format, or Fortran 90 fixed format
code?

Using file externsion is not always reliable as one may use
1) fixed format Fortran 90 code in .f90 file (extension .f90 is often used
for Fortran 90 free format codes),
2) fixed format Fortran 90 code in .f file (extension .f is often used for
Fortran 77 codes).
-------------------------------------


On Wed, 11 Dec 2002, eric jones wrote:

> > What extensions are you using for those fixed format Fortran 90 files?
> 
> Our legacy code base uses .f90 for its fixed format files.

That's the worst case and I guess you are not willing to change .f90 to
.f? Note that some compilers use extension to determine the
format: f90|f95 is free and anything else is fixed format. Though they
usually have also option to redefine this convention.
Anyway, I think the option (2) should resolve also this case.

> > Here follows two possible solutions to this issue:
> > 
> > 1) Always use for|ftn|f extension for Fixed format Fortran codes
> >    and as an F77 compiler, use Fortran 90 (if available) in Fixed
> >    format mode. For example, for Absoft compiler we would have
> >      self.f77_compiler = 'f90'
> >      self.f77_switches = '-f fixed ...'
> >    and never use f77 compiler.
> > 
> > 2) To determine the format mode of a Fortran source file, first check
> >    its first line. If the first line contains (following Emacs
> >    convention)
> >       -*- fortran -*-
> >    then the format is Fixed. If the file extension is f90|f95, then
> >    use Fortran 90 compiler in Fixed format mode. Otherwise, use F77
> >    compiler.
> >    If the line contains
> >       -*- f90 -*-
> >    then the format is Free.
> >    If the above tests fail, then use file extension for determining
> >    the format mode.
> > 
> > What do you think?
> 
> (2) sounds fine to me.  On the other hand, I'm happy for the user to
> have to specify the compiler flag for this in which case you don't have
> to do anything to the current rules.  
>
> Hmmm.  Actually, maybe we could add a 'fixed=1' keyword to Extension().
> This would allow the same setup.py file to work no matter what compiler
> is specified.  The downside of this is that it treats all files as fixed
> format which doesn't allow the mixing of fixed and free format files.
> In practice, I haven't needed to do this, but I'm sure that need is
> there.  

I think it is rather common case to have legacy Fortran 77 code
(say, anything from netlib) and free Fortran 90 codes mixed.

> This is one of distutils downpoints anyway -- you can't specify
> compile options on a per file basis, so I guess we're really not
> breaking anything that isn't already broken. 

I'd acctually avoid introducing any new features to distutils unless there
are no other ways to resolve a problem. I understand that 'fixed=1' would
work immidiately in your case but when one uses mixed free/fixed sources
then this option is useless and some other solutions needs to be worked
out anyway. The option (2) would solve it but has downsides also: one must
add these header lines to Fortran codes and that might not be always
desired, e.g. for 3rd party codes. But I don't have any better ideas for a
general solution right now. 
Though users have always an option to build the problematic libraries
themself and specify them as external objects or libraries in scipy.py.

> Do you think others on the list will have comments on this?  I think
> that Robert Ferrell has a large f90 code base that he works with also.
> Maybe he'd have an opinion.

I certainly hope so. So, I CC'ed this message to scipy-dev.

<snip>
> > However, in your particular example case, F2PY could split the use
> > statement into a number of use statements for each variable to avoid
> > continuations. I'll see what I can do...
> 
> Thanks.

The patch is in f2py CVS.

> > But the problem of Fortran 77/Fixed Fortran 90/Free Fortran 90 codes
> still
> > needs to be resolved.
> 
> I think suggestion (2) above sounds good, but I'd also like to be able
> to do it from the Extension() as I described above.  Its nice just to
> define a switch to get the code working instead of having to edit a
> legacy code base to insert the needed comments...

OK, this can be implemented at the same time when adding
extra_fortran_compiler_flags feature. Though I really hope that you
would change your mind on adding "fixed=1" feature ;-)

Pearu