date:20171214

[Cmake-commits] CMake branch, master, updated. v3.10.1-628-g4549eed

2017-12-14 Thread 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  4549eed94706d20ebbb1e8187f5b028c7bd4aa2e (commit)
  from  0d1b6c89dcefa4d2d690d5ed030022c82b5503bd (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=4549eed94706d20ebbb1e8187f5b028c7bd4aa2e
commit 4549eed94706d20ebbb1e8187f5b028c7bd4aa2e
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Dec 15 00:01:19 2017 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Dec 15 00:01:19 2017 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 3556f94..28a9ffa 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 10)
-set(CMake_VERSION_PATCH 20171214)
+set(CMake_VERSION_PATCH 20171215)
 #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] Configuration under CMake 3.10.1 fails but succeeds with 3.9.6

2017-12-14 Thread Alan W. Irwin


On 2017-12-14 13:51-0500 Michael Jackson wrote:


I just tried out the latest CMake release 3.10.1 and it fails to configure (from a 
clean build directory) our project where CMake 3.9.x and below (down to CMake 3.7.x) 
configures it completely and correctly. The configure error I get is"

-- Configuring done
CMake Error in 
/Users/mjackson/Workspace/DREAM3D_Plugins/AskNDEToolbox/Applications/ScanViewer/CMakeLists.txt:
 Cannot find source file:

   
/Users/mjackson/Workspace/DREAM3D-Build/3.10.1/Plugins/AskNDEToolbox/qrc_AskNDEToolbox.cpp

 Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
 .hxx .in .txx




Now, the funny thing about this is that nowhere in the CMakeLists

files for the "ScaneViewer" application should it be adding the
generated qrc_AskNDEToolbox.cpp file. That file is added higher up in
the heirarchy of projects, but not that particular application. Does
anyone have any thoughts on this issue?

Hi Michael:

This is just speculation but I wonder if you are inheriting a property
from higher in the directory tree, that you weren't inheriting before?

By the way, once you solve this, I would recommend for your peace of
mind that you arrange with the CMake developers for a contract test
for your project.  See examples of this in Tests/Contracts in the git
master branch of CMake where such contract tests have already been
enabled for PLplot, Trilinos, and VTK.  The idea of such contracts is
you configure your computer to automatically build and test the staged
version of CMake (the version the CMake developers want to be
thoroughly tested that typically changes from one night to the next). 
And one of those tests is the contract test you configure where you

build some version of your project (that you change from time to time
to some recent well-tested version such as your latest release).

The results of such tests are automatically reported at
.  Note, my recent
"raven" results there demonstrate success for all CMake tests including
"Contracts.PLplot".  Both the PLplot and CMake software projects
benefit from this "contract".  I am assured I get early warning of any
bad interactions between staged CMake changes and the build system for
my software (such as you discovered above), and the CMake developers
get some real build-system testing (as opposed to their usual unit
tests which obviously found no issues with 3.10.1) of the staged version of
CMake that they need to test to evaluate what commits from their
staged version get into the next release.

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

[CMake] Configuration under CMake 3.10.1 fails but succeeds with 3.9.6

2017-12-14 Thread Michael Jackson

I just tried out the latest CMake release 3.10.1 and it fails to configure 
(from a clean build directory) our project where CMake 3.9.x and below (down to 
CMake 3.7.x) configures it completely and correctly. The configure error I get 
is"

-- Configuring done
CMake Error in 
/Users/mjackson/Workspace/DREAM3D_Plugins/AskNDEToolbox/Applications/ScanViewer/CMakeLists.txt:
  Cannot find source file:


/Users/mjackson/Workspace/DREAM3D-Build/3.10.1/Plugins/AskNDEToolbox/qrc_AskNDEToolbox.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

Now, the funny thing about this is that nowhere in the CMakeLists files for the 
"ScaneViewer" application should it be adding the generated 
qrc_AskNDEToolbox.cpp file. That file is added higher up in the heirarchy of 
projects, but not that particular application. Does anyone have any thoughts on 
this issue?

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net


-- 

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-developers] [ANNOUNCE] CMake 3.10.1 available for download

2017-12-14 Thread Robert Maynard

We are pleased to announce that CMake 3.10.1 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.10.1 since 3.10.0:

Adam Ciarciński (1):
  bootstrap: Check support for unordered_map from compiler mode

Alexander Wittig (1):
  CPack: Fix macOS PKG component dependency information

Brad King (3):
  CUDA: Treat /usr/include as an implicit include directory
  server: Revert "Report backtraces in codemodel response"
  CMake 3.10.1

Christian Pfeiffer (4):
  FindMPI: Correct legacy variable handling
  FindMPI: Fix multiple configure runs
  FindMPI: Fix various legacy problems
  IRSL: Fix MSVC variable deferencing

Islam Amer (1):
  IAR: FindBinUtils should work for CXX as well as C

Matthew Woehlke (4):
  GoogleTest: Fix multiple discovery on same target
  GoogleTest: Improve gtest_discover_tests messages
  GoogleTest: Add timeout to discovery
  GoogleTest: Add test for missing test executable

Robert Maynard (1):
  CUDA: Shared libraries on Darwin properly setup @rpath install_names

Sebastian Holtermann (2):
  Autogen: Fix for AUTOMOC on macOS frameworks in CMake 3.10
  Autogen: Tests: Add test for MacOS frameworks

İsmail Dönmez (1):
  Clang: Do not mistake clang-cl 6.0 for GNU-like clang
-- 

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

[CMake] [ANNOUNCE] CMake 3.10.1 available for download

2017-12-14 Thread Robert Maynard

We are pleased to announce that CMake 3.10.1 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.10.1 since 3.10.0:

Adam Ciarciński (1):
  bootstrap: Check support for unordered_map from compiler mode

Alexander Wittig (1):
  CPack: Fix macOS PKG component dependency information

Brad King (3):
  CUDA: Treat /usr/include as an implicit include directory
  server: Revert "Report backtraces in codemodel response"
  CMake 3.10.1

Christian Pfeiffer (4):
  FindMPI: Correct legacy variable handling
  FindMPI: Fix multiple configure runs
  FindMPI: Fix various legacy problems
  IRSL: Fix MSVC variable deferencing

Islam Amer (1):
  IAR: FindBinUtils should work for CXX as well as C

Matthew Woehlke (4):
  GoogleTest: Fix multiple discovery on same target
  GoogleTest: Improve gtest_discover_tests messages
  GoogleTest: Add timeout to discovery
  GoogleTest: Add test for missing test executable

Robert Maynard (1):
  CUDA: Shared libraries on Darwin properly setup @rpath install_names

Sebastian Holtermann (2):
  Autogen: Fix for AUTOMOC on macOS frameworks in CMake 3.10
  Autogen: Tests: Add test for MacOS frameworks

İsmail Dönmez (1):
  Clang: Do not mistake clang-cl 6.0 for GNU-like clang
-- 

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, master, updated. v3.10.1-598-g1e148ab

2017-12-14 Thread 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  1e148aba7078359e2e5b4d7080a6e1cb6592d94a (commit)
   via  9b4d31dc771f630961d903df318f1539ddd955d1 (commit)
  from  1e2911b8cd512663ef35bf05de0b5f8156abc171 (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=1e148aba7078359e2e5b4d7080a6e1cb6592d94a
commit 1e148aba7078359e2e5b4d7080a6e1cb6592d94a
Merge: 1e2911b 9b4d31d
Author: Brad King 
AuthorDate: Thu Dec 14 13:08:00 2017 +
Commit: Kitware Robot 
CommitDate: Thu Dec 14 08:08:05 2017 -0500

Merge topic 'cmGraphVizWriter_Interface_Dependers'

9b4d31dc cmGraphVizWriter: Updated to create and follow dependers for 
interface targets

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b4d31dc771f630961d903df318f1539ddd955d1
commit 9b4d31dc771f630961d903df318f1539ddd955d1
Author: Joel T. Frederico 
AuthorDate: Fri Dec 8 21:27:24 2017 -0800
Commit: Brad King 
CommitDate: Thu Dec 14 08:03:02 2017 -0500

cmGraphVizWriter: Updated to create and follow dependers for interface 
targets

Generating graphs of dependencies now uses interface targets, but graphs
of dependers did not include interface targets.

diff --git a/Source/cmGraphVizWriter.cxx b/Source/cmGraphVizWriter.cxx
index dd2993d..e684f5e 100644
--- a/Source/cmGraphVizWriter.cxx
+++ b/Source/cmGraphVizWriter.cxx
@@ -29,6 +29,22 @@ enum LinkLibraryScopeType
 const char* const GRAPHVIZ_PRIVATE_EDEGE_STYLE = "dashed";
 const char* const GRAPHVIZ_INTERFACE_EDEGE_STYLE = "dotted";
 
+std::string getLinkLibraryStyle(const LinkLibraryScopeType& type)
+{
+  std::string style;
+  switch (type) {
+case LLT_SCOPE_PRIVATE:
+  style = "[style = " + std::string(GRAPHVIZ_PRIVATE_EDEGE_STYLE) + "]";
+  break;
+case LLT_SCOPE_INTERFACE:
+  style = "[style = " + std::string(GRAPHVIZ_INTERFACE_EDEGE_STYLE) + "]";
+  break;
+default:
+  break;
+  }
+  return style;
+}
+
 const char* getShapeForTarget(const cmGeneratorTarget* target)
 {
   if (!target) {
@@ -132,6 +148,7 @@ cmGraphVizWriter::cmGraphVizWriter(
   , GenerateForStaticLibs(true)
   , GenerateForSharedLibs(true)
   , GenerateForModuleLibs(true)
+  , GenerateForInterface(true)
   , GenerateForExternals(true)
   , GeneratePerTarget(true)
   , GenerateDependers(true)
@@ -192,6 +209,7 @@ void cmGraphVizWriter::ReadSettings(const char* 
settingsFileName,
   __set_bool_if_set(this->GenerateForStaticLibs, "GRAPHVIZ_STATIC_LIBS");
   __set_bool_if_set(this->GenerateForSharedLibs, "GRAPHVIZ_SHARED_LIBS");
   __set_bool_if_set(this->GenerateForModuleLibs, "GRAPHVIZ_MODULE_LIBS");
+  __set_bool_if_set(this->GenerateForInterface, "GRAPHVIZ_INTERFACE");
   __set_bool_if_set(this->GenerateForExternals, "GRAPHVIZ_EXTERNAL_LIBS");
   __set_bool_if_set(this->GeneratePerTarget, "GRAPHVIZ_GENERATE_PER_TARGET");
   __set_bool_if_set(this->GenerateDependers, "GRAPHVIZ_GENERATE_DEPENDERS");
@@ -379,16 +397,7 @@ void cmGraphVizWriter::WriteConnections(
 
   str << "\"" << myNodeName << "\" -> \"" << libNameIt->second << "\"";
 
-  switch (llit.second) {
-case LLT_SCOPE_PRIVATE:
-  str << "[style = " << GRAPHVIZ_PRIVATE_EDEGE_STYLE << "]";
-  break;
-case LLT_SCOPE_INTERFACE:
-  str << "[style = " << GRAPHVIZ_INTERFACE_EDEGE_STYLE << "]";
-  break;
-default:
-  break;
-  }
+  str << getLinkLibraryStyle(llit.second);
 
   str << " // " << targetName << " -> " << libName << std::endl;
   this->WriteConnections(libName, insertedNodes, insertedConnections, str);
@@ -429,12 +438,11 @@ void cmGraphVizWriter::WriteDependerConnections(
 
 // Now we have a target, check whether it links against targetName.
 // If so, draw a connection, and then continue with dependers on that one.
-const cmTarget::LinkLibraryVectorType* ll =
-  &(tptr.second->Target->GetOriginalLinkLibraries());
+std::map ll =
+  getScopedLinkLibrariesFromTarget(tptr.second->Target);
 
-for (auto const& llit : *ll) {
-  std::string libName = llit.first;
-  if (libName == targetName) {
+for (auto const& llit : ll) {
+  if (llit.first == targetName) {
 // So this target links against targetName.
 std::map::const_iterator dependerNodeNameIt =
   this->TargetNamesNodes.find(tptr.first);
@@ -452,6 +460,7 @@ void

Re: [CMake] CMake fixup_bundle for ubuntu 16.04

2017-12-14 Thread Konstantin Tokarev



13.12.2017, 23:08, "Daniel Schepler" :
> You would need to set the INSTALL_RPATH property of the targets to something 
> like "$ORIGIN/../lib" .
>
> You might also need to add "-Wl,--disable-new-dtags" to the 
> CMAKE_*_LINK_FLAGS variables - otherwise, the RPATH settings will only take 
> effect for direct dependencies of the executables (and any plugins or shared 
> libraries) you build but not for dependencies of these dependencies.
>
> (We also tend not to include copies of glibc or OpenGL libraries - for the 
> former, that tends to have issues if there are any mismatches between the 
> exact build of glibc included in the installer and the NSS modules from the 
> system.  For the latter, the OpenGL libraries vary too much between Mesa and 
> the NVidia and AMD proprietary driver versions for any one of them to work on 
> all systems.)

Note that if your application loads at least one library from the host system, 
you must use system libc.

(Also, bundling libc requires rewriting of loader (INTERP ELF header), it can 
be done with patchelf --set-interpreter)

> --
> Daniel Schepler
> 
> From: CMake [cmake-boun...@cmake.org] on behalf of Waldo Valenzuela via CMake 
> [cmake@cmake.org]
> Sent: Wednesday, December 13, 2017 11:15 AM
> To: Miklos Espak
> Cc: cmake@cmake.org
> Subject: Re: [CMake] CMake fixup_bundle for ubuntu 16.04
>
> Dear Miklos,
>
> thanks for the email, and your suggestions, but the problem with fixup_bundle 
> in ubuntu is that is not fixing the libraries locations from the executables 
> meaning:
>
> if I execute the idd command like this “ idd ./app” where “app” is the 
> executable, the locations of the library is still is “no found", that should 
> be in the location that was copy after running the INSTALL.
>
> when you set LD_LIBRARY_PATH is for a temporally solution, or permanent if I 
> modified the environment configuration of O.S.. The idea is that I want to 
> create a standalone application.
>
> Under this scenario, if I have an executable called “app” and a shared 
> library call “lib.so”, fixup_bundle should fix the location of the “lib.so” 
> in the same folder where is “app”.
>
> Then if I run the command "idd ./app” the output should be:
>
> lib.so => “”, where  is folder where is located “app"
>
> Cheers,
>
> Waldo.
>
>> On 13 Dec 2017, at 03:58, Miklos Espak  wrote:
>>
>> Hi,
>>
>> you need to add the directory where the Qt libs have been installed (along 
>> with your application binaries) to the LD_LIBRARY_PATH. In your case it is 
>> '/home/waldo/Developer/install/Release/bratumia/bin/', as I see.
>>
>> Also, you do *not* need to add the Qt plugin directories to the library 
>> path. The plugins are loaded at run-time. So that they can be found, you 
>> need to install a qt.conf file in the bin directory with the following 
>> contents:
>>
>> [Paths]
>> Prefix=.
>>
>> You also do *not* need to add "/usr/lib" and "/usr/lib/x86-..." to the 
>> library path. These libraries are searched for by default. If you did it 
>> because your Qt installation is there, that's wrong. The fixup_bundle 
>> function should have copied the necessary Qt libs in the install bin folder, 
>> so you just need to add that folder to the path.
>>
>> Also, make sure that the DIRS variable contains all the directories where 
>> there are libraries to install, including dependencies.
>>
>> I hope that helps.
>>
>> Best regards,
>> Miklos
>>
>> On 11 December 2017 at 19:07, Waldo Valenzuela via CMake  
>> wrote:
>>> Dear All,
>>>
>>> I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and 
>>> Mac no problem to created the standalone app, but in Ubuntu 16.04  I have 
>>> several problems.
>>>
>>> I am using CodeBlocks to compile and run the app, and from CodeBlocks when 
>>> I run the app there is no problem, it work normally like in windows and 
>>> mac, but after run the installation, and If I want to run the app from the 
>>> installation folder (./app ) I have several problems.
>>>
>>> the CMakeList.txt is
>>>
>>> FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS 
>>> ${QT_BASE_DIRECTORY}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>>> FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS 
>>> ${QT_BASE_DIRECTORY}/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})
>>>
>>> SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})
>>>
>>> MESSAGE("Project libraries: ${QTPLUGINS}")
>>>
>>> INSTALL(CODE "
>>>         INCLUDE(BundleUtilities)
>>>         FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
>>>              "
>>>         COMPONENT ${PROJECT_NAME})
>>>
>>> First I have this:
>>>
>>> -- fixup_bundle: fixing...
>>> -- 132/260: fix-up not required on this platform 
>>> '/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
>>> -- 133/260: fix-up not required on this platform 
>>>

Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

2017-12-14 Thread CHEVRIER, Marc

I think you can fill a bug about erroneous behaviour when a list is specified 
with command set_target_properties for property 
IMPORTED_LINK_INTERFACE_LIBRARIES.

Another way to specify the property is to use command set_property which 
supports multiple values for a property:
set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB)

From: CMake  on behalf of Saad Khattak 

Date: Thursday 14 December 2017 at 03:20
To: Craig Scott 
Cc: Cmake Mailing List 
Subject: Re: [CMake] Using SET_TARGET_PROPERTIES and 
IMPORTED_LINK_INTERFACE_LIBRARIES

Thanks Craig for your reply.

The issue is that both "LibA" and "LibB" have been set using "add_library(LibA 
STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and both have some 
properties that are being set.

Ultimately, CMake recognizes LibA and LibB as CMake library projects, and they 
have their own include and link directories and other library dependencies.

The nice thing about using LibA directly is then LibD inherits all the include 
and link directories of LibA and LibB which then get inherited by any library 
or executable that includes LibD (and ultimately, the whole point of modern 
CMake):

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as IMPORTED 
CMake libraries
)

If I use "LibA;LibB" then first, I have to manually extract the library names 
of the imported CMake libraries LibA and LibB. Then, I have to call 
"target_include_directories" and "target_link_libraries" for all dependencies 
of LibA and LibB, even though these dependencies were defined in their own 
respective CMake files when calling "add_library(LibA STATIC IMPORTED)"

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer recognizes 
LibA and LibB as IMPORTED CMake libraries
)

Regards,
Saad

On Wed, Dec 13, 2017 at 4:32 PM Craig Scott 
> wrote:
On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak 
> wrote:
Hi,

I have several imported libraries:

LibA
LibB
LibC

Where each imported library has been populated by (where ${LIB_NAME} is either 
LibA, LibB or LibC):

add_library(${LIB_NAME} STATIC IMPORTED)

And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set 
properly:

set_target_properties(${LIB_NAME}
PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
   "location/of/library.lib"
)

Now let's say I have another imported library LibD that depends on LibA and 
LibB such that any executable that uses LibD must also link with LibA and LibB. 
To do that, I use:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
  )

You probably want this instead:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
)

Note that if the property value is a list, you have to provide it as a single 
string (i.e. "LibA;LibB" rather than LibA LibB)

--
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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

Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

2017-12-14 Thread Petr Kmoch

Hi Saad,

have you read the docs on IMPORTED_LINK_INTERFACE_LIBRARIES? (
https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LINK_INTERFACE_LIBRARIES.html
):

  "This property is deprecated. Use INTERFACE_LINK_LIBRARIES instead."

Setting INTERFACE_LINK_LIBRARIES to "LibA;LibB" should do exactly what you
want.

As a side note, the shorthand funciton set_target_properties() and friends
are best suited when multiple properties to one value each. When setting a
list, it's usually more convenient to use the general set_property():

set_property(
  TARGET LibD
  PROPERTY INTERFACE_LINK_LIBRARIES
  LibA LibB
)

Petr


On 14 December 2017 at 03:19, Saad Khattak  wrote:

> Thanks Craig for your reply.
>
> The issue is that both "LibA" and "LibB" have been set using
> "add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and
> both have some properties that are being set.
>
> Ultimately, CMake recognizes LibA and LibB as CMake library projects, and
> they have their own include and link directories and other library
> dependencies.
>
> The nice thing about using LibA directly is then LibD inherits all the
> include and link directories of LibA and LibB which then get inherited by
> any library or executable that includes LibD (and ultimately, the whole
> point of modern CMake):
>
> set_target_properties(LibD
>   PROPERTIES
> IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as
> IMPORTED CMake libraries
> )
>
> If I use "LibA;LibB" then first, I have to manually extract the library
> names of the imported CMake libraries LibA and LibB. Then, I have to call
> "target_include_directories" and "target_link_libraries" for all
> dependencies of LibA and LibB, even though these dependencies were defined
> in their own respective CMake files when calling "add_library(LibA STATIC
> IMPORTED)"
>
> set_target_properties(LibD
>   PROPERTIES
> IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer
> recognizes LibA and LibB as IMPORTED CMake libraries
> )
>
> Regards,
> Saad
>
> On Wed, Dec 13, 2017 at 4:32 PM Craig Scott 
> wrote:
>
>> On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak 
>> wrote:
>>
>>> Hi,
>>>
>>> I have several imported libraries:
>>>
>>> LibA
>>> LibB
>>> LibC
>>>
>>> Where each imported library has been populated by (where ${LIB_NAME} is
>>> either LibA, LibB or LibC):
>>>
>>> add_library(${LIB_NAME} STATIC IMPORTED)
>>>
>>> And each library has the properties IMPORT_LOCATION_${CONFIGURATION}
>>> set properly:
>>>
>>> set_target_properties(${LIB_NAME}
>>> PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>>>"location/of/library.lib"
>>> )
>>>
>>> Now let's say I have another imported library LibD that depends on LibA
>>> and LibB such that any executable that uses LibD must also link with LibA
>>> and LibB. To do that, I use:
>>>
>>> set_target_properties(LibD
>>>   PROPERTIES
>>> IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>>>   )
>>>
>>
>> You probably want this instead:
>>
>> set_target_properties(LibD
>>   PROPERTIES
>> IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
>> )
>>
>>
>> Note that if the property value is a list, you have to provide it as a
>> single string (i.e. "LibA;LibB" rather than LibA LibB)
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>
> --
>
> 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

[Cmake-commits] CMake branch, master, updated. v3.10.1-628-g4549eed

Re: [CMake] Configuration under CMake 3.10.1 fails but succeeds with 3.9.6

[CMake] Configuration under CMake 3.10.1 fails but succeeds with 3.9.6

[cmake-developers] [ANNOUNCE] CMake 3.10.1 available for download

[CMake] [ANNOUNCE] CMake 3.10.1 available for download

[Cmake-commits] CMake branch, master, updated. v3.10.1-598-g1e148ab

Re: [CMake] CMake fixup_bundle for ubuntu 16.04

Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

9 matches

Site Navigation

Mail list logo

Footer information