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

[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] gitlab.kitware.com sign in

[Brad King]

On 04/19/2017 04:12 PM, 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.  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.

No, GitLab is a whole new service.  It is far more than a bug tracker
and has no way to migrate users from Mantis.  Please sign up for a new
account.  If you already have a github.com account you can use that
to register and authenticate via GitHub OAuth.  Otherwise just doing
a normal username/password registration is fine.

-Brad

-- 

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

[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

Re: [cmake-developers] [DISCUSSION] CMake Localization (L10N)

[Alex Turbov]

absolutely agreed.


On Wed, Apr 19, 2017 at 1:52 PM, Domen Vrankar 
wrote:

> 2017-04-18 19:16 GMT+02:00 Konstantin Podsvirov 
> :
>
>> Draft code:
>>
>> > set(GREETING "greeting message" # Optional default value
>> >  en "Hello, world!"
>> >  ru "Привет, мир!")
>> >
>> > set(CMAKE_OUTPUT_LOCALE "en") # Or CMAKE_L10N_LOCALE...
>> >
>> > message("$L10N{GREETING}") # Hello, world!
>> >
>> > set(CMAKE_OUTPUT_LOCALE "fr")
>> >
>> > message("$L10N{GREETING}") # greeting text
>> >
>> > message("$L10N:ru{GREETING}") # Привет, мир!
>>
>> Any feedback?
>
>
> Coming from a small country I'm not too keen on localization as it makes
> my life harder - in case of an error I have to guess what the english
> version of the error message would look like just to get results on Google.
>
> I somewhat understand the wish of non programmers to see text in their own
> language but for developers english is de facto programming standard
> language so I don't see a reason for such an addition.
>
> That being said I'd suggest a more generic alternative that can be used
> for things other than localization:
>
> Access by array position:
> > set(GREETING "greeting message" "Hello, world!" "Привет, мир!")
> > message(${GREETING}) # prints "greeting message"
> > message(${GREETING:0}) # also prints "greeting message"
> > message(${GREETING:1}) # prints "Hello, world!"
> > message(${GREETING:2}) # prints "Привет, мир!"
> where the underlying structure of GREETING is "greeting message;Hello,
> world!;Привет, мир!"
>
> Or taking that even further by defining maps:
> > set(GREETING "greeting message" "en:Hello, world!" "ru:Привет, мир!")
> > message(${GREETING}) # prints "greeting message"
> > message(${GREETING:}) # also prints "greeting message"
> > message(${GREETING:en}) # prints "Hello, world!"
> > message(${GREETING:ru}) # prints "Привет, мир!"
> where the underlying structure of GREETING is "greeting message;en:Hello,
> world!;ru:Привет, мир!"
>
> This could then be used for e.g. for creating enums e.g.:
> > set(BUILD_TYPE_OPTIONS "default_flags" "Debug:debug_flags"
> "Release:release_flags" ...)
> > message("using flags:  ${CMAKE_BUILD_TYPE_OPTIONS:${CMAKE_BUILD_TYPE}}")
> # error if outside of range (e.g. OddRelease was specified for
> CMAKE_BUILD_TYPE)
>
> For this to really be useful support for if() command would also be
> required.
>
> Regards,
> Domen
>
>
> --
>
> 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
>
-- 

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] [DISCUSSION] CMake Localization (L10N)

[Brad King]

On 04/19/2017 02:52 AM, Domen Vrankar wrote:
> I somewhat understand the wish of non programmers to see text in
> their own language but for developers english is de facto programming
> standard language so I don't see a reason for such an addition.

This is a good point.  I'd be hesitant to move forward with anything
in upstream CMake without broader interest.

> Or taking that even further by defining maps:
>> set(GREETING "greeting message" "en:Hello, world!" "ru:Привет, мир!")
>> message(${GREETING}) # prints "greeting message"
>> message(${GREETING:}) # also prints "greeting message"
>> message(${GREETING:en}) # prints "Hello, world!"
>> message(${GREETING:ru}) # prints "Привет, мир!"

This can be done already in the CMake language:

```
set("en.GREETING" "Hello world!")
set("ru.GREETING" "Привет, мир!")
set(l10n ru)
message(STATUS "${${l10n}.GREETING}") # Привет, мир!
```

A macro or function could be used to improve the ergonomics of
defining the table.

-Brad

-- 

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