Add flag to support Fortran 90/95?

[sethrj]

I've encountered a few projects that include Fortran-90 bindings and are unable to use Fortran-2003 bindings. Legacy C/Fortran compatibility can be achieved, at least for numeric types, with the correct configure-time determination of symbol mangling using such codes as CMake. Is this worth implementing?

If Fortran 90/95 compatibility is needed for your library's users: please leave a comment so I can gauge the interest in this capability. I'm particularly interested in understanding what prevents such projects from compiling with the Fortran 2003 standard. (Available compilers, code infrastructure, etc.) Thanks!

[aprokop]

@nuraiman

[sethrj]

@xiaoyeli SuperLU
@mkstoyanov TASMANIAN

[mkstoyanov]

Regarding the current project that I'm in collaboration, we are still investigating so I cannot give a definitive answer (yet).

In the past, I have worked with people that insists on Fortran 90 ether because they are unfamiliar or uncomfortable with OOP and/or other features of 2003, or because they want to appeal to people that are unfamiliar/uncomfortable. I even know a case where the devs were holing back from using 2003 features in order to provide "better compatibility", but after some introspection into the code, it turned out that they were indeed using some 2003 features without any compatibility complaints but with the artificial restriction to not use the full 2003 language.

[sethrj]

OK @mkstoyanov that's good news, because SWIG can generate "non-object-oriented" interfaces that can still guarantee cross-language compatibility.

[xiaoyeli]

@sethrj @mkstoyanov
I don't use any fancy features in my Fortran90 interface, only modules. I would think Fortran2003 compiler would work.

[nuraiman]

Hi all, we are interested in Fortran 90 interface.

[sethrj]

Hi @nuraiman ! Can you please provide some detail on incompatibility with FORTRAN 2003? If it’s just the object oriented design or do your compilers have missing features? Thanks!

[rcoacci]

One of the issues I usually see is that for one reason or another we're forced to use very old compilers. In my work for example I have to support Intel ifort 10.0 on a CentOS5 (we call it a "platform"). Since I'm mostly using swig to generate bindc bindings for C libraries, I'm not seeing many issues, but I had to disable support for said "platform" for my libraries, because ifort 10 doesn't support some of the constructs generated (I think enumerations was one of them).

I don't know what others think but perhaps allowing only bindc bindings with Fortran 90 flag is a middle ground? It's highly probable that those requiring Fortran 90 won't be able to use more than basic ISO C BINDING anyway.

[mkstoyanov]

@rcoacci So you are stuck with supporting a 13 year old system from before the existence of the iPhone and you have no chance of upgrading to a 12 year old system and ifort 11 which has full Fotran 2003 support (according to wikipedia).

I feel for you.

[sethrj]

Holy christ. I feel for you too, but it's not surprising. The glacial pace of fortran compiler support for fundamental language features makes it reasonable to allow toggling of some features... I'm pretty sure most compilers still have problems with the FINAL feature. GCC didn't get it working until version 8 I think...

@rcoacci Is your SWIG Fortran input using

%fortranbindc;
%fortranconst;

to eliminate wrappers? Is the enum, bind(c) the only incompatible feature? I could add a flag to use integer, parameter instead of enum.

[rcoacci]

@sethrj yes, mostly I'm using only fortranbindc and fortranconst. One of the reasons is to keep compatibility with pre-swig "wrappers" even on more modern systems. Fortunately, my libs aren't required (yet) to support that ifort 10 system, and I've heard rumors that there is a huge upgrade of that system on the way, so I don't think I'll need that flag, but thanks.

@mkstoyanov well until last year my workstation (and some clusters!) were still CentOS6, now I'm working on a CentOS7 and most clusters are also CentOS7, so we're having some progress.