[Cmake-commits] CMake branch, master, updated. v3.14.2-742-g44c6acc

2019-04-17 Thread Kitware Robot via Cmake-commits
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  44c6acc053ebaf0565408a1395ea1bde5d105305 (commit)
  from  2ed688a863671d58513055ad56ab04d6be05295b (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=44c6acc053ebaf0565408a1395ea1bde5d105305
commit 44c6acc053ebaf0565408a1395ea1bde5d105305
Author: Kitware Robot 
AuthorDate: Thu Apr 18 00:01:03 2019 -0400
Commit: Kitware Robot 
CommitDate: Thu Apr 18 00:01:03 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b7b278b..d4d5da5 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 14)
-set(CMake_VERSION_PATCH 20190417)
+set(CMake_VERSION_PATCH 20190418)
 #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
https://cmake.org/mailman/listinfo/cmake-commits


Re: [CMake] Linked Imported Library in Visual Studio Showing NOTFOUND

2019-04-17 Thread Dustyn Blasig
Ah, thanks, that was it.

So when I use find_library(), it finds the .lib portion on Windows. Is
there a way to find the .dll portion as well?

Also, if I change the library type to STATIC on Windows, that seems to have
the same effect on the linkers command line as leaving it as SHARED but
changing the library property from IMPORTED_LOCATION to IMPORTED_IMPLIB.
Are there other differences?

If someone has a nice online example of a "best practice" for fining the
.dll/.lib/.so portions and setting them up, I'd love to take a look.

Thx!

On Wed, Apr 17, 2019 at 6:50 AM Petr Kmoch  wrote:

> Hi Dustyn,
>
> ELF platforms link against .so files, but Windows links against import
> libraries (.lib files) assocaited with DLLs. Does the target 'bar' have the
> IMPORTED_IMPLIB property set up correctly? (See
> https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_IMPLIB.html )
>
> Petr
>
> On Tue, 16 Apr 2019 at 21:37, Dustyn Blasig  wrote:
>
>> Hi All,
>>
>> I'm trying to debug an issues where an imported shared library is showing
>> up in the linker command as not found, but within the CMake generation the
>> target seems to exist.
>>
>> # CMakeLists.txt 
>>
>> include(bar.cmake)
>>
>> add_library(foo SHARED)
>>
>> if(TARGET bar)
>>   target_link_libraries(foo PUBLIC bar)
>> endif()
>>
>> # bar.cmake ###
>>
>> add_library(bar SHARED IMPORTED)
>>
>> ...
>>
>>
>> On Linux, the link command contains the correct *-L* and
>> *-lbar* options. However, on Windows (Visual Studio) the linker command
>> has "bar-NOTFOUND" instead of bar.lib as it should, even though bar should
>> only be added as a dependency *if* it exists.
>>
>> How can I debug why this would happen? Is there a way to have CMake dump
>> more information about that target?
>>
>> 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:
>> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake


[Cmake-commits] CMake branch, release, updated. v3.14.2-8-gc648551

2019-04-17 Thread Kitware Robot via Cmake-commits
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, release has been updated
   via  c648551bea65c6457f21b608f31c4ccd5b69a0fa (commit)
   via  844050adaf4ff28356a14b34d3ec73f36e843339 (commit)
  from  09fba6146fa726a83cbbccc3d5fb288f7f14f111 (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 -
---

Summary of changes:
 Modules/FindOpenGL.cmake | 3 +++
 1 file changed, 3 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.14.2-741-g2ed688a

2019-04-17 Thread Kitware Robot via Cmake-commits
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  2ed688a863671d58513055ad56ab04d6be05295b (commit)
   via  fb3370b6a1681190ffd8daf63975c44ce8fc1c49 (commit)
   via  5cd187147ecbd29a0afc5a6b49f2232b61a1ab8c (commit)
   via  0238295c7e9d19340e968b766d6d0cf07fc5af50 (commit)
   via  c648551bea65c6457f21b608f31c4ccd5b69a0fa (commit)
   via  8e4899fd6cb3518723710f7ba57d28ef058518c0 (commit)
   via  f621e7fa5df8d35cc379f9f7825f3d75b8489876 (commit)
  from  87609eebf390bdf183aab80061ee9fa2fbdbc17a (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=2ed688a863671d58513055ad56ab04d6be05295b
commit 2ed688a863671d58513055ad56ab04d6be05295b
Merge: 5cd1871 fb3370b
Author: Brad King 
AuthorDate: Wed Apr 17 15:01:03 2019 +
Commit: Kitware Robot 
CommitDate: Wed Apr 17 11:01:37 2019 -0400

Merge topic 'msvc-runtime-library'

fb3370b6a1 MSVC: Add abstraction for runtime library selection
f621e7fa5d VS: Fix Fortran runtime library flag map special case for '-' 
options

Acked-by: Kitware Robot 
Acked-by: Ben Boeckel 
Acked-by: Leonid Pospelov 
Merge-request: !3211


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fb3370b6a1681190ffd8daf63975c44ce8fc1c49
commit fb3370b6a1681190ffd8daf63975c44ce8fc1c49
Author: Brad King 
AuthorDate: Wed Apr 10 13:38:41 2019 -0400
Commit: Brad King 
CommitDate: Wed Apr 17 11:00:44 2019 -0400

MSVC: Add abstraction for runtime library selection

Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
abstraction to select the runtime library from an enumeration of logical
names.  We've long hesitated to do this because the idea of "runtime
library selection" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.

Removing the old default flags requires a policy because existing
projects may rely on string processing to edit them and choose a runtime
library under the old behavior.  Add policy CMP0091 to provide
compatibility.

Fixes: #19108

diff --git a/Help/command/try_compile.rst b/Help/command/try_compile.rst
index ca8fc77..0bc2ca3 100644
--- a/Help/command/try_compile.rst
+++ b/Help/command/try_compile.rst
@@ -135,6 +135,7 @@ default values:
 * :variable:`CMAKE_ENABLE_EXPORTS`
 * :variable:`CMAKE_LINK_SEARCH_START_STATIC`
 * :variable:`CMAKE_LINK_SEARCH_END_STATIC`
+* :variable:`CMAKE_MSVC_RUNTIME_LIBRARY`
 * :variable:`CMAKE_POSITION_INDEPENDENT_CODE`
 
 If :policy:`CMP0056` is set to ``NEW``, then
diff --git a/Help/manual/cmake-policies.7.rst b/Help/manual/cmake-policies.7.rst
index e89ea3da..043fb5c 100644
--- a/Help/manual/cmake-policies.7.rst
+++ b/Help/manual/cmake-policies.7.rst
@@ -57,6 +57,7 @@ Policies Introduced by CMake 3.15
 .. toctree::
:maxdepth: 1
 
+   CMP0091: MSVC runtime library flags are selected by an abstraction. 

CMP0090: export(PACKAGE) does not populate package registry by default. 

CMP0089: Compiler id for IBM Clang-based XL compilers is now XLClang. 

 
diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index 4d4b9ff..3da9144 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -280,6 +280,7 @@ Properties on Targets
/prop_tgt/MACOSX_RPATH
/prop_tgt/MANUALLY_ADDED_DEPENDENCIES
/prop_tgt/MAP_IMPORTED_CONFIG_CONFIG
+   /prop_tgt/MSVC_RUNTIME_LIBRARY
/prop_tgt/NAME
/prop_tgt/NO_SONAME
/prop_tgt/NO_SYSTEM_FROM_IMPORTED
diff --git a/Help/manual/cmake-variables.7.rst 
b/Help/manual/cmake-variables.7.rst
index 18dd9d7..22e8add 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -386,6 +386,7 @@ Variables that Control the Build
/variable/CMAKE_MODULE_LINKER_FLAGS_CONFIG_INIT
/variable/CMAKE_MODULE_LINKER_FLAGS_INIT
/variable/CMAKE_MSVCIDE_RUN_PATH
+   /variable/CMAKE_MSVC_RUNTIME_LIBRARY
/variable/CMAKE_NINJA_OUTPUT_PATH_PREFIX
/variable/CMAKE_NO_BUILTIN_CHRPATH
/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED
diff --git a/Help/policy/CMP0091.rst b/Help/policy/CMP0091.rst
new file mode 100644
index 000..5b7c4e3
--- /dev/null
+++ b/Help/policy/CMP0091.rst
@@ -0,0 +1,47 @@
+CMP0091
+---
+
+MSVC runtime library flags are selected by an abstraction.
+
+Compilers targeting the MSVC ABI have flags to select the MSVC runtime library.
+Runtime library selection typically varies with build configuration because
+there is a separate runtime 

[Cmake-commits] CMake branch, master, updated. v3.14.2-734-g87609ee

2019-04-17 Thread Kitware Robot via Cmake-commits
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  87609eebf390bdf183aab80061ee9fa2fbdbc17a (commit)
   via  844050adaf4ff28356a14b34d3ec73f36e843339 (commit)
  from  8d5eb9787885d21d5d20630473c11a79250ca28e (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=87609eebf390bdf183aab80061ee9fa2fbdbc17a
commit 87609eebf390bdf183aab80061ee9fa2fbdbc17a
Merge: 8d5eb97 844050a
Author: Brad King 
AuthorDate: Wed Apr 17 14:43:23 2019 +
Commit: Kitware Robot 
CommitDate: Wed Apr 17 10:44:05 2019 -0400

Merge topic 'libglvnd-subdir'

844050adaf FindOpenGL: look for GLVND libraries with a libglvnd suffix

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=844050adaf4ff28356a14b34d3ec73f36e843339
commit 844050adaf4ff28356a14b34d3ec73f36e843339
Author: Ben Boeckel 
AuthorDate: Mon Apr 15 15:37:59 2019 -0400
Commit: Brad King 
CommitDate: Wed Apr 17 10:16:46 2019 -0400

FindOpenGL: look for GLVND libraries with a libglvnd suffix

On CentOS 6.10, the libglvnd package from EPEL installs its libraries
under a libglvnd subdirectory.

diff --git a/Modules/FindOpenGL.cmake b/Modules/FindOpenGL.cmake
index 832dca2..00db033 100644
--- a/Modules/FindOpenGL.cmake
+++ b/Modules/FindOpenGL.cmake
@@ -205,11 +205,13 @@ else()
   find_library(OPENGL_glx_LIBRARY
 NAMES GLX
 PATHS ${_OPENGL_LIB_PATH}
+PATH_SUFFIXES libglvnd
   )
 
   find_library(OPENGL_egl_LIBRARY
 NAMES EGL
 PATHS ${_OPENGL_LIB_PATH}
+PATH_SUFFIXES libglvnd
   )
 
   find_library(OPENGL_glu_LIBRARY
@@ -264,6 +266,7 @@ else()
 /usr/openwin/lib
 /usr/shlib
 ${_OPENGL_LIB_PATH}
+  PATH_SUFFIXES libglvnd
   )
   endif()
 

---

Summary of changes:
 Modules/FindOpenGL.cmake | 3 +++
 1 file changed, 3 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits


Re: [CMake] Linked Imported Library in Visual Studio Showing NOTFOUND

2019-04-17 Thread Petr Kmoch
Hi Dustyn,

ELF platforms link against .so files, but Windows links against import
libraries (.lib files) assocaited with DLLs. Does the target 'bar' have the
IMPORTED_IMPLIB property set up correctly? (See
https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_IMPLIB.html )

Petr

On Tue, 16 Apr 2019 at 21:37, Dustyn Blasig  wrote:

> Hi All,
>
> I'm trying to debug an issues where an imported shared library is showing
> up in the linker command as not found, but within the CMake generation the
> target seems to exist.
>
> # CMakeLists.txt 
>
> include(bar.cmake)
>
> add_library(foo SHARED)
>
> if(TARGET bar)
>   target_link_libraries(foo PUBLIC bar)
> endif()
>
> # bar.cmake ###
>
> add_library(bar SHARED IMPORTED)
>
> ...
>
>
> On Linux, the link command contains the correct *-L* and *-lbar*
> options. However, on Windows (Visual Studio) the linker command has
> "bar-NOTFOUND" instead of bar.lib as it should, even though bar should only
> be added as a dependency *if* it exists.
>
> How can I debug why this would happen? Is there a way to have CMake dump
> more information about that target?
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc.

2019-04-17 Thread Stephen Morris
It turns out that the solution is to replace "$(TargetPath)" and "$(TargetDir)" 
with the CMake generator expressions "`$`" and 
"`$`", respectively, viz:

set_target_properties(myApplication PROPERTIES 
VS_DEBUGGER_WORKING_DIRECTORY "$"
   VS_DEBUGGER_COMMAND  
 "$"
   VS_DEBUGGER_ENVIRONMENT  
 "PATH=%PATH%;${CMAKE_PREFIX_PATH}/bin")




From: Stephen Morris
Sent: 16 April 2019 17:36
To: cmake@cmake.org
Subject: Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc.

I’m trying to use the new VS_DEBUGGER_WORKING_DIRECTORY and VS_DEBUGGER_COMMAND 
properties to facilitate debugging in a CMake-generated Visual Studio project 
file (in my case Visual Studio 2013).

Everything else in my configuration works except this…

I’ve noted from ‘regular’ Visual Studio project files (i.e. ones not generated 
from CMake that, in the “Configuration Properties/Debugging” dialog, the 
‘Command’ and ‘Working Directory’ fields are populated by default with 
$(TargetPath) and $(TargetDir) respectively. So in my CMakeLists.txt file, I 
have:

set_target_properties(myApplication PROPERTIES 
VS_DEBUGGER_WORKING_DIRECTORY "$(TargetDir)"

   VS_DEBUGGER_COMMAND"$(TargetPath)"

   VS_DEBUGGER_ENVIRONMENT  
"%PATH%;C:\\Qt\\5.9.7\\msvc2013_64\\bin")

[In fact I've tried this with and without the quotes around $(TargetDir) and 
$(TargetPath) and the result is the same each time; they're absolutely 
necessary around the path.]

What happens is that I then build the application, go to the “Configuration 
Properties/Debugging” dialog and verify that it looks exactly the same as a 
normal project file, with $(TargetDir) and $(TargetPath) appearing exactly 
where they should do. It doesn't work though; when I try to debug I get a 
message saying "Unable to start debugging. Check your debugger settings..."

So I delete the text $(TargetDir) and $(TargetPath) from the dialog, then type 
them in again exactly as before: and then it works perfectly.

What am I doing wrong?
-- 

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:
https://cmake.org/mailman/listinfo/cmake