[cmake-developers] [Feature Request] Fortran standards compliance for various compilers

Alan W. Irwin irwin at beluga.phys.uvic.ca
Sat Apr 22 15:19:35 EDT 2017


On 2017-04-22 11:30-0000 Christian Pfeiffer wrote:

> On 4/22/2017 7:33 AM, C Bergström wrote:
>
>> On Thu, Apr 20, 2017 at 4:12 AM, Alan W. Irwin
>> <irwin at beluga.phys.uvic.ca> wrote:
[...]
>>> Especially since that Fortran information is already collected in
>>> well-organized form in on one place, namely
>>> <http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>.
>> With my Fortran compiler vendor hat on - Please do be aware that this
>> list of supported features may not be 100% accurate.
>>
> On 4/22/2017 7:33 AM, C Bergström wrote:
>> #1 Vendors can add support that hasn't been reflected in that document
>>
>> #2 Not all claimed support is created equal. There's quite a few F2K3
>> OO features that someone can claim to support, but when you start
>> digging into real code they just flat out fail. (maybe less of the
>> case now than it was before)
>>
>> #3 F2K8 aka CAF features could be supported, but may require
>> additional runtime libraries or 3rd party software to actually work.
>> For example our implementation ties to specific hardware and may not
>> be 100% portable. Other implementations may depend on OpenMPI and not
>> work with MPICH.
>>
>> I guess I'm saying that auto-detecting this stuff is cool, but do
>> ensure that someone can easily override it. If as a vendor I say we
>> support F2K8 and I'd like that enabled by default for supported
>> versions of the compiler I really don't want to fight against some
>> auto-test which might think otherwise.
>

Agreed.

> I reckon working with the document is the most accurate option, though.

Agreed! CMake is well ahead of the game here because of the existence
of this well-maintained document.  Furthmore, the document can be
parsed (see discussion of that at
<https://gitlab.kitware.com/cmake/cmake/issues/16819>) which is
another big advantage for the CMake developers.  My impression from
the forward of this document is this is a collection of information
that is supplied by the various vendors, but apparently they have been
reasonably honest about that assessment because there are lots of
non-"Y" results in the tables (for no claimed support for a given
sub-feature).  (See the overall totals for "Y" results that I
tabulated at <https://gitlab.kitware.com/cmake/cmake/issues/16819>
which for many vendors show far less than complete compliance with the
Fortran 2003 and Fortran 2008 standards.

So if a vendor does not claim support for a given sub-feature of the
Fortran 2003 and Fortran 2008 standards with a "Y", then I believe
them!  But as I think everyone will agree here, if they claim support
for a given sub-feature with a "Y", then that claim has to be taken
with a grain of salt by developers of CMake-based build systems for
Fortran projects and the users of such projects.

> It should be possible tooverride it somehow, since it can't be
> completely accurate nor updating outside of its 6-month cycle.

I assume this extremely useful Fortran information from CMake would
only be informational, and it would be up to developers of CMake-based
build-systems what they did with that useful (especially for the
non-"Y" case) information. And the documentation of the proposed
CMAKE_Fortran_KNOWN_FEATURES feature should make that useful
distinction between lack of claim for support (likely reliable), and
claim of support (substantially less reliable).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the cmake-developers mailing list