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

2017-04-22 Thread Alan W. Irwin 

On 2017-04-22 11:30- 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
 wrote:

[...]

Especially since that Fortran information is already collected in
well-organized form in on one place, namely
.

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
) 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 
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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2017-04-22 Thread Christian Pfeiffer 
On 4/22/2017 7:33 AM, C Bergström wrote:

> On Thu, Apr 20, 2017 at 4:12 AM, Alan W. Irwin
>  wrote:
>> On 2017-04-19 07:27+0200 Rolf Eike Beer wrote:
>>
  What would really be useful is a list containing
 what Fortran features from the Fortran 2003 and 2008 standards that the
 given Fortran compiler supports.  That information is already
>>>
>>> To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and
>>> friends, no?
>>
>> I wasn't aware of CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES,
>> but now that I have looked them up, I agree adding
>> CMAKE_Fortran_KNOWN_FEATURES is the right way to go rather than the
>> generic list I proposed above.
>>
>>> This exactly sounds like the whole compile_features things
>>> already done for C and C++, so yet another language shouldn't be too hard
>>> I
>>> guess.
>>
>> Especially since that Fortran information is already collected in
>> well-organized form in on one place, namely
>> .
> With my Fortran compiler vendor hat on - Please do be aware that this
> list of supported features may not be 100% accurate.
>
> #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.
>
>
> Thanks

I reckon working with the document is the most accurate option, though. 
It should be possible tooverride it somehow, since it can't be 
completely accurate nor updating outside of its 6-month cycle.
Coarrays need special treatment in CMake anyways. Right now, there's no 
way of determining which is the right way to enable Coarrays, if any.

Right now, in Intel Fortran, there's a number of related compiler 
switches, permitting anything from distributed to single image Coarrays, 
see https://software.intel.com/en-us/node/691534 .Each of these will 
also pull in different libraries that would need detection.

GFortran is even worse in this regard, since GCC 4.6, they've been able 
to support single images via -fcoarray=single, in GCC 4.7 they've got a 
barebones implementation using a communications library and since 5, 
that implementation is claimed to be "fully supported [...] except of 
bugs and incomplete support of special cases". Not to mention that GCC 
does not ship any useful communications library on their own, but rather 
relies on the external projects, see https://gcc.gnu.org/wiki/CoarrayLib 
, and can only support Coarrays in a useful fashion if an ABI compatible 
implementation like OpenCoarrays is installed on the system meaning 
feature completion also depends on some external library.

Either way, Coarrays should be the only feature in need of exceptional 
treatment, and for any other Fortran feature, it should be sufficient to 
work in a way comparable as to how C/C++ is being handled today.

- Chris
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2017-04-21 Thread C Bergström 
On Thu, Apr 20, 2017 at 4:12 AM, Alan W. Irwin
 wrote:
> On 2017-04-19 07:27+0200 Rolf Eike Beer wrote:
>
>>>  What would really be useful is a list containing
>>> what Fortran features from the Fortran 2003 and 2008 standards that the
>>> given Fortran compiler supports.  That information is already
>>
>>
>> To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and
>> friends, no?
>
>
> I wasn't aware of CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES,
> but now that I have looked them up, I agree adding
> CMAKE_Fortran_KNOWN_FEATURES is the right way to go rather than the
> generic list I proposed above.
>
>> This exactly sounds like the whole compile_features things
>> already done for C and C++, so yet another language shouldn't be too hard
>> I
>> guess.
>
>
> Especially since that Fortran information is already collected in
> well-organized form in on one place, namely
> .

With my Fortran compiler vendor hat on - Please do be aware that this
list of supported features may not be 100% accurate.

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


Thanks
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2017-04-19 Thread Alan W. Irwin 

On 2017-04-19 13:12-0700 Alan W. Irwin wrote:


It appears we are in consensus so it is time to put this idea into the
bug tracker as a feature request.


OK. It was a bit of a struggle, but with list help from Brad with a
different subject line I finally got registered and generated the
desired feature request (CMake issue #16819).  Good luck to the CMake
developers in dealing with this issue.

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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2017-04-19 Thread Alan W. Irwin 

On 2017-04-19 07:27+0200 Rolf Eike Beer wrote:


 What would really be useful is a list containing
what Fortran features from the Fortran 2003 and 2008 standards that the
given Fortran compiler supports.  That information is already


To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and
friends, no?


I wasn't aware of CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES,
but now that I have looked them up, I agree adding
CMAKE_Fortran_KNOWN_FEATURES is the right way to go rather than the
generic list I proposed above.


This exactly sounds like the whole compile_features things
already done for C and C++, so yet another language shouldn't be too hard I
guess.


Especially since that Fortran information is already collected in
well-organized form in on one place, namely
.

It appears we are in consensus so it is time to put this idea into the
bug tracker as a feature request.  However, when I attempted to do
that following your FAQ, I could not get access to
 with the login identity
ir...@beluga.phys.uvic.ca.  I have never used that bug tracker before,
but I thought at least that login identity would have be copied from
the old Mantis bugtracker.  But using my old Mantis bugtracker
password failed and clicking on "forgot password" or "Request a new
one" (which presumably should work even if gitlab does not have
ir...@beluga.phys.uvic.ca registered as a login identity) did not send
any e-mail response at all to the above address.  And, yes, all mail
gets through to me except that spam_bayes sorts it into the INBOX,
sb_unsure, and sb_spam folders based solely on word counts, and mail
from your gitlab bug tracker showed up at none of those places after a
~half hour wait.

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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers