[Cmake-commits] CMake branch, master, updated. v3.8.0-810-g3452f8b

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  3452f8b209176873288139572ac9a47f216ecfa1 (commit)
  from  44f0d2d9913595e214048b6d5a2b9ab2e9d1cf46 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3452f8b209176873288139572ac9a47f216ecfa1
commit 3452f8b209176873288139572ac9a47f216ecfa1
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Apr 20 00:01:06 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Apr 20 00:01:06 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 9219dae..737087f 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 8)
-set(CMake_VERSION_PATCH 20170419)
+set(CMake_VERSION_PATCH 20170420)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Cmake-commits] CMake branch, master, updated. v3.8.0-809-g44f0d2d

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  44f0d2d9913595e214048b6d5a2b9ab2e9d1cf46 (commit)
   via  9db9bb27ea3f3dd3db3913c2bc2233f03018d5b0 (commit)
   via  a7e0453a3238cbd617cf2fff7388fd3d879dfd65 (commit)
   via  334efdebb8c69e6327fecb42ed1ae3cfcdb1cad6 (commit)
   via  c79e7e09a83cb6cd8bfde600ce492f0429236a02 (commit)
   via  9e338b57b7a7094b150e10512e6fd758e19eac8c (commit)
   via  2790ffc96f4e52017718bd1ce3fe1ef70ccae2d2 (commit)
   via  f1e51ec3a5b3ed54dec054aa422fdd7a81b078b3 (commit)
   via  eb08e1febba1cdc71bea2aee6431b5ed8f711af2 (commit)
   via  8dd997526370c4d1232bcde46e0eb2a751dfa3fd (commit)
   via  a0091a697e275a86a493e4fd87902a0eb9067d55 (commit)
   via  eeb58c5c34a888acbb422e66ff7895cb35c9322a (commit)
   via  3ed9f63551c2b51af60088b85625c4ce71512aa8 (commit)
   via  eec93bceec5411e4409b5e3ee5dc301fca6fcbfd (commit)
   via  93c89bc75ceee599ba7c08b8fe1ac5104942054f (commit)
   via  ac0cf7ff4f5a846381593cf28ebbc9cfaf107149 (commit)
   via  8577978c580d09abc56fa39f387a3991c91c31ba (commit)
   via  26cfd039a9479959da1d893bcee5b2aa879da6c0 (commit)
   via  25f3f22a1a952b98e7dc6772ef5fedd4932d0901 (commit)
   via  d596c5504e8ee9e1cc51ddbf7a29815dd07fc05f (commit)
   via  930042f2d95e83047231457f4d9134c74b8744fc (commit)
   via  3ab4681efa6db7339af36218fffea165ad1186f3 (commit)
   via  86979bb533a7835fc20f87b1f9d74590ebec4915 (commit)
  from  89310b0b2025c0ceee7a3e6c50da88b6e2cf92ca (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=44f0d2d9913595e214048b6d5a2b9ab2e9d1cf46
commit 44f0d2d9913595e214048b6d5a2b9ab2e9d1cf46
Merge: 9db9bb2 eec93bc
Author: Brad King 
AuthorDate: Wed Apr 19 14:47:28 2017 +
Commit: Kitware Robot 
CommitDate: Wed Apr 19 10:47:31 2017 -0400

Merge topic 'objlib-extend'

eec93bce Allow OBJECT libraries to be installed, exported, and imported
93c89bc7 Genex: Allow TARGET_OBJECTS to be used everywhere
ac0cf7ff Genex: Reject TARGET_OBJECTS on non-object libraries earlier
8577978c Tests: ExportImport C code should use explicit (void) in prototypes
26cfd039 cmInstallTargetGenerator: Re-order GenerateScriptForConfig logic
25f3f22a cmGlobalGenerator: Add method to check if object file location is 
known
d596c550 cmGeneratorTarget: Add method to get the object file directory
930042f2 cmGeneratorTarget: Factor out a GetTargetObjectNames method
...

Acked-by: Kitware Robot 
Merge-request: !712


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9db9bb27ea3f3dd3db3913c2bc2233f03018d5b0
commit 9db9bb27ea3f3dd3db3913c2bc2233f03018d5b0
Merge: a7e0453 eeb58c5
Author: Brad King 
AuthorDate: Wed Apr 19 14:43:03 2017 +
Commit: Kitware Robot 
CommitDate: Wed Apr 19 10:47:00 2017 -0400

Merge topic 'test-CheckIPOSupported'

eeb58c5c Tests: Add cases for typical CheckIPOSupported usage

Acked-by: Kitware Robot 
Merge-request: !700


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7e0453a3238cbd617cf2fff7388fd3d879dfd65
commit a7e0453a3238cbd617cf2fff7388fd3d879dfd65
Merge: 334efde 9e338b5
Author: Brad King 
AuthorDate: Wed Apr 19 14:42:33 2017 +
Commit: Kitware Robot 
CommitDate: Wed Apr 19 10:46:10 2017 -0400

Merge topic 'fix-CMakeTestAllGenerators'

9e338b57 Tests: Drop machine-specific logic from CMakeTestAllGenerators
2790ffc9 Tests: Run CMakeTestAllGenerators serially
f1e51ec3 Tests: Fix CMakeTestAllGenerators generator list

Acked-by: Kitware Robot 
Merge-request: !720


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=334efdebb8c69e6327fecb42ed1ae3cfcdb1cad6
commit 334efdebb8c69e6327fecb42ed1ae3cfcdb1cad6
Merge: c79e7e0 eb08e1f
Author: Brad King 
AuthorDate: Wed Apr 19 14:42:23 2017 +
Commit: Kitware Robot 
CommitDate: Wed Apr 19 10:45:41 2017 -0400

Merge topic 'doc-CMAKE_MATCH_n'

eb08e1fe Help: Document CMAKE_MATCH_ variables
8dd99752 Help: Link from if(MATCHES) to regex specification docs
a0091a69 Help: Format string() command regex specification docs

Acked-by: Kitware Robot 
Merge-request: !719


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c79e7e09a83cb6cd8bfde600ce492f0429236a02
commit 

[Cmake-commits] CMake branch, master, updated. v3.8.0-786-g89310b0

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  89310b0b2025c0ceee7a3e6c50da88b6e2cf92ca (commit)
   via  872d08ad348eba019e56c3eb7c1cc4929c417eba (commit)
   via  3022545f14a38d07105de0555c75e445c5b587a6 (commit)
   via  86787633f8440fcb3bd3fd96018134a6c5157e9c (commit)
  from  3d3144bb023a98392594038973576cfbf046c039 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89310b0b2025c0ceee7a3e6c50da88b6e2cf92ca
commit 89310b0b2025c0ceee7a3e6c50da88b6e2cf92ca
Merge: 872d08a 3022545
Author: Brad King 
AuthorDate: Wed Apr 19 14:42:11 2017 +
Commit: Kitware Robot 
CommitDate: Wed Apr 19 10:43:21 2017 -0400

Merge topic 'doc-find-path-sep'

3022545f Help: Document find command search path separators

Acked-by: Kitware Robot 
Merge-request: !718


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=872d08ad348eba019e56c3eb7c1cc4929c417eba
commit 872d08ad348eba019e56c3eb7c1cc4929c417eba
Merge: 3d3144b 8678763
Author: Brad King 
AuthorDate: Wed Apr 19 14:41:55 2017 +
Commit: Kitware Robot 
CommitDate: Wed Apr 19 10:42:10 2017 -0400

Merge topic 'cmake-gui-desktop-icon-wayland'

86787633 cmake-gui:  Fix display of icon under Wayland.

Acked-by: Kitware Robot 
Merge-request: !715


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3022545f14a38d07105de0555c75e445c5b587a6
commit 3022545f14a38d07105de0555c75e445c5b587a6
Author: Brad King 
AuthorDate: Tue Apr 18 14:22:20 2017 -0400
Commit: Brad King 
CommitDate: Tue Apr 18 14:22:20 2017 -0400

Help: Document find command search path separators

The `find_*` commands read search paths from both CMake variables
and from environment variables.  Document how multiple values in
these variables should be separated.

Fixes: #16800

diff --git a/Help/command/FIND_XXX.txt b/Help/command/FIND_XXX.txt
index bd4d295..2f27764 100644
--- a/Help/command/FIND_XXX.txt
+++ b/Help/command/FIND_XXX.txt
@@ -73,6 +73,7 @@ If ``NO_DEFAULT_PATH`` is not specified, the search process 
is as follows:
 
 1. Search paths specified in cmake-specific cache variables.
These are intended to be used on the command line with a ``-DVAR=value``.
+   The values are interpreted as :ref:`;-lists `.
This can be skipped if ``NO_CMAKE_PATH`` is passed.
 
* |CMAKE_PREFIX_PATH_XXX|
@@ -80,7 +81,9 @@ If ``NO_DEFAULT_PATH`` is not specified, the search process 
is as follows:
* |CMAKE_XXX_MAC_PATH|
 
 2. Search paths specified in cmake-specific environment variables.
-   These are intended to be set in the user's shell configuration.
+   These are intended to be set in the user's shell configuration,
+   and therefore use the host's native path separator
+   (``;`` on Windows and ``:`` on UNIX).
This can be skipped if ``NO_CMAKE_ENVIRONMENT_PATH`` is passed.
 
* |CMAKE_PREFIX_PATH_XXX|
diff --git a/Help/command/find_package.rst b/Help/command/find_package.rst
index 2cb1e5f..60a77b8 100644
--- a/Help/command/find_package.rst
+++ b/Help/command/find_package.rst
@@ -251,6 +251,7 @@ enabled.
 
 1. Search paths specified in cmake-specific cache variables.  These
are intended to be used on the command line with a ``-DVAR=value``.
+   The values are interpreted as :ref:`;-lists `.
This can be skipped if ``NO_CMAKE_PATH`` is passed::
 
  CMAKE_PREFIX_PATH
@@ -258,7 +259,9 @@ enabled.
  CMAKE_APPBUNDLE_PATH
 
 2. Search paths specified in cmake-specific environment variables.
-   These are intended to be set in the user's shell configuration.
+   These are intended to be set in the user's shell configuration,
+   and therefore use the host's native path separator
+   (``;`` on Windows and ``:`` on UNIX).
This can be skipped if ``NO_CMAKE_ENVIRONMENT_PATH`` is passed::
 
  _DIR

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86787633f8440fcb3bd3fd96018134a6c5157e9c
commit 86787633f8440fcb3bd3fd96018134a6c5157e9c
Author: Clinton Stimpson 
AuthorDate: Mon Apr 17 16:44:06 2017 -0600
Commit: Clinton Stimpson 
CommitDate: Mon Apr 17 16:48:25 2017 -0600

cmake-gui:  Fix display of icon under Wayland.

Fixes: #16797

diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index 10fd718..2e11a8a 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -198,7 +198,7 @@ if(UNIX 

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

[Domen Vrankar]

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

Re: [CMake] Question about transitive deps and static libs.

[Petr Kmoch]

Hi,

I will offer an alternative phrasing based on what makes me personally
understand this best. It might potentially be useful for the documentation
update you're planning.

`target_link_libraries(A B)` specifies that the code in A needs B to be
added to the produced binary when the binary is *linked*. However, static
libraries are not produced by linking, but by an archiver or librarian
tool. Therefore, B needs to be present for the actual linking step when
this happens further down the chain (when linking an executable or shared
library), regardless of the "privacy" of B in A.

Petr

On 18 April 2017 at 17:44, Eric Noulard  wrote:

> Answering to myself.
>
> This mail by Craig explains a lot:
> https://cmake.org/pipermail/cmake/2016-May/063400.html
>
> Sorry for the noise. I guess I have my answer in there.
> I'll try to propose a documentation update based on Craig's explanation
> because,
> https://cmake.org/cmake/help/v3.8/manual/cmake-buildsystem.
> 7.html#transitive-usage-requirements
>
> does not contains clues on specific treatment for static libs.
>
>
>
>
> 2017-04-18 16:30 GMT+02:00 Eric Noulard :
>
>> I have a question concerning the transitive linking of dependence and
>> static libs.
>>
>> I'm working a on prokect where some shared lib are linked to static lib
>> (do not ask me why).
>> So I do:
>>
>> set(CMAKE_POSITION_INDEPENDENT_CODE True)
>>
>> then I have a bunch of libraries (either static or shared) which depends
>> on each other.
>> I use PRIVATE and PUBLIC specification with target_link_librairies.
>>
>> Now I expected that the transitive link properties would be fullfilled
>> simply i.e. that
>> when some target LIB1 is PRIVATEly link against say pthread. Then if a
>> another
>> lib LIB2 is linked against LIB1 then then "pthread" wouldn't be dragged
>> into the link
>> interface of LIB2.
>>
>> It seems that this is not as simple as I thought and as soon as LIB1 is
>> static
>> then LIB2 gets the dependency (be it PRIVATE or PUBLIC)...
>>
>> Find attached a small example.
>>
>> Is this a bug, a feature or something I didn't catch?
>>
>>
>> --
>> Eric
>>
>
>
>
> --
> Eric
>
> --
>
> 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
>
-- 

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