[Cmake-commits] CMake branch, master, updated. v3.10.1-596-g1e2911b

[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  1e2911b8cd512663ef35bf05de0b5f8156abc171 (commit)
  from  e80cc856da6901338486d9183b527fbcbbe385dd (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=1e2911b8cd512663ef35bf05de0b5f8156abc171
commit 1e2911b8cd512663ef35bf05de0b5f8156abc171
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Dec 14 00:01:11 2017 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Dec 14 00:01:11 2017 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index ddb7826..3556f94 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 20171213)
+set(CMake_VERSION_PATCH 20171214)
 #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] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

[Saad Khattak]

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

[Craig Scott]

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

[CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

[Saad Khattak]

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
  )

However, the above syntax is incorrect and CMake complains that
SET_TARGET_PROPERTIES was called with incorrect number of arguments.

So I thought maybe the following will work:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA
IMPORTED_LINK_INTERFACE_LIBRARIES LibB
  )

Although this time CMake doesn't complaint, only LibB's libraries are
linked ultimately, LibA is overwritten. Doing the following, of course,
doesn't work because LibA is now an imported library and not exactly a
variable that can be used directly:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "${LibA};${LibB}" # not correct
because LibA and LibB are CMake imported libraries, not direct paths to
libraries
  )

Is there any way to specify, for an imported target, multiple dependencies
on other libraries (and/or dependencies on other imported libraries).

Thanks,
Saad
-- 

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] CMake fixup_bundle for ubuntu 16.04

[Waldo Valenzuela via CMake]

Dear Daniel,

Thanks for the email, I was trying different combinations of 
CMAKE_INSTALL_RPATH, with full and relative paths and were not working, I did 
not about the link flags, thanks for the advice I will test it. 

Also, the relative onces is not clear for me, if I set  "$ORIGIN/../lib”, this 
is reconstructed from the installation directory of the executable of from 
cpack tmp directory where is copy during the packaged process.

In this topic are missing examples in the CMake documentation 
(https://cmake.org/Wiki/CMake_RPATH_handling), here they do not mention nothing 
about the flags also.

Also, I am completely agree with you regarding the OpenGL, vary too much 
between the different venders.

Best regards,

Waldo

> On 13 Dec 2017, at 20:32, Daniel Schepler  
> wrote:
> 
> 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.)
> -- 
> 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} 

Re: [CMake] CMake fixup_bundle for ubuntu 16.04

[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.)
--
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 
'/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
-- 134/260: fix-up not required on this platform 
'/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5’

-- 167/260: fix-up not required on this platform 
'/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
-- 168/260: fix-up not required on this platform 
'/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
-- 169/260: fix-up not required on this platform 
'/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1

then when I run: ldd ./app I have:

Re: [CMake] CMake fixup_bundle for ubuntu 16.04

[Waldo Valenzuela via CMake]

Dear Konstantin,


Thanks for the email, yes you are right, I was looking this tool time ago, but 
the fixup_bundle is just a part of the bigger problem, meaning if I want to 
create a DEB  package with CMake/CPack, how I could tell CPACK to use 
linuxdeployqt, in runtime.


CMake/CPack in windows and mac osx are doing their job, but in linux no, in 
linux we need to many additional tools to create a package.

Cheers,

Waldo.

> On 13 Dec 2017, at 20:19, Konstantin Tokarev  wrote:
> 
>  
>  
> 13.12.2017, 22:16, "Waldo Valenzuela via CMake"  >:
>> 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"
>  
> Use linuxdeployqt (https://github.com/probonopd/linuxdeployqt 
> )
>  
>>  
>> 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 
>>> '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
>>> -- 134/260: fix-up not required on this platform 
>>> '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5’
>>> 
>>> -- 167/260: fix-up not required on this platform 
>>> '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
>>> -- 168/260: fix-up not required on this platform 
>>> '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
>>> -- 169/260: fix-up not required on this platform 
>>> 

Re: [CMake] CMake fixup_bundle for ubuntu 16.04

[Konstantin Tokarev]

  13.12.2017, 22:16, "Waldo Valenzuela via CMake" :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" Use linuxdeployqt (https://github.com/probonopd/linuxdeployqt)  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 isFILE(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 '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'-- 134/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5’-- 167/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'-- 168/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'-- 169/260: fix-up not required on this platform '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1then when I run: ldd ./app I have:        libQt5Concurrent.so.5 => not found        libvtkRenderingImage-9.0.so.1 => not found        libvtkRenderingVolumeOpenGL2-9.0.so.1 => not foundthen if I fix manually the path of the libraries like this:export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/waldo/app/bin/plugins/platforms"I can run the application from through the command line from the installation folder, but I have this message and I can not see nothingQXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabledQOpenGLWidget: Failed to create contextcomposeAndFlush: makeCurrent() failedI think that the FIXUP_BUNDLE is doing nothing.Any help is welcome.Best regards,Waldo.--Powered by www.kitware.comPlease keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQKitware offers various services to support the CMake community. For more information on each offering, please visit:CMake Support: http://cmake.org/cmake/help/support.htmlCMake Consulting: 

Re: [CMake] CMake fixup_bundle for ubuntu 16.04

[Waldo Valenzuela via CMake]

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 
> '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
> -- 134/260: fix-up not required on this platform 
> '/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5’
> 
> -- 167/260: fix-up not required on this platform 
> '/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
> -- 168/260: fix-up not required on this platform 
> '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
> -- 169/260: fix-up not required on this platform 
> '/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBioRad-4.13.so.1
> 
> then when I run: ldd ./app I have:
> 
> libQt5Concurrent.so.5 => not found
> libvtkRenderingImage-9.0.so.1 => not found
> libvtkRenderingVolumeOpenGL2-9.0.so.1 => not found
> 
> then if I fix manually the path of the libraries like this:
> 
> export 
> LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib:/usr/lib/x86_64-linux-gnu:/home/waldo/app/bin/plugins/imageformats:/home/waldo/app/bin/plugins/platforms"
> 
> I can run the application from through the command line from the installation 
> folder, but I have this message and I can not see nothing
> 
> QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL 
> are enabled
> QOpenGLWidget: Failed to create context
> composeAndFlush: makeCurrent() failed
> 
> 
> I think that the FIXUP_BUNDLE is doing nothing.
> 
> Any help is welcome.
> 
> Best regards,
> 
> Waldo.
> --
> 
> Powered by www.kitware.com 
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> 

[Cmake-commits] CMake annotated tag, v3.10.1, created. v3.10.1

[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 annotated tag, v3.10.1 has been created
at  15849e8ff7383e08ce5a7600e5ca6ef65cc4ac7e (tag)
   tagging  166bf4c490b8f46eca057fc23c3f3c2e042e9cb3 (commit)
  replaces  v3.10.0
 tagged by  Brad King
on  Wed Dec 13 09:30:29 2017 -0500

- Log -
CMake 3.10.1
-BEGIN PGP SIGNATURE-

iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAloxOYUWHGJyYWQua2lu
Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhHp0D/9VjzUbx1aWNSIw5SG1bYfvnegD
/tLR9JAtjjCjxZLww4o6OaAhXdwxhAnNbRYjQihgM68hpNkjKKFV06mml+1dFID8
j49k5PGnfJOf5aBl+bYSrFMqFCEDTGj0kLS4otFoIUfVz5Wj0WbABvlQWQGBqn8u
qEYvbYpjbCVIwKtEVpGg7tkEGjOzdOT/vwB0LX5o1zEuQbNn1qhXhZ6uPpjh0z6z
wbr567D43m9Gh/2DI0QYn66uqIVabrOz1GWmPtgpD1GTGUs87AWdtFp0tgDfYCIX
jTwBHmUuoX5b2Ay+iSfCiCW6xRM7FJhEoM1jCM7PMjlAOSYom+m0X9zcnX6b632r
dfCBCG0sQpd2KaRLLu3SCo79CIRihQPgis8cuxFcZMKDd66LJvfuQOrfYU3KswWG
PjphcGFvw7QC9r+Cn1HsKlEQ/cE7JxVdFnaMMDtijRDyl18KL35+qTKRiyRAqNQA
eYLUiy83bew6U+th1L5DMquEHw+Rj4fSUJmjwb911RYCE2hxyzns21magTUAQ0qC
pU8mwls45X/Z4Vx2++/OH7r6xLS7O19/VvC0hW1oqweumeRx4dZNcRa/+5i1TPny
fIx5P/qTaeMtPSdAIa6Kvq3F6IjwQMysGiFoRtReUxW8wasmCOr7CwuBthtiPPwC
RZrjZIAdEv/JIITXrQ==
=/oHw
-END PGP SIGNATURE-

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 (17):
  Merge branch 'gtest-fix-discovery' into release-3.10
  CUDA: Treat /usr/include as an implicit include directory
  Merge branch 'cuda-implicit-include-dirs' into release-3.10
  Merge branch 'clang-cl-fix' into release-3.10
  Merge branch 'bootstrap-clang-5' into release-3.10
  Merge branch 'cpack-pkg-fix' into release-3.10
  Merge branch 'findmpi-found-cond' into release-3.10
  Merge branch 'findmpi-notfound-spam' into release-3.10
  server: Revert "Report backtraces in codemodel response"
  Merge branch 'backport-revert-server-target-backtraces' into release-3.10
  Merge branch 'gtest-discovery-timeout' into release-3.10
  Merge branch 'automoc-apple-framework' into release-3.10
  Merge branch 'cuda_darwin_proper_install_names_flags' into release-3.10
  Merge branch 'fix-iar-binutils-for-cxx' into release-3.10
  Merge branch 'findmpi-builtin-fix' into release-3.10
  Merge branch 'irsl-msvc-omp-fix' into release-3.10
  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

---


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

[Cmake-commits] CMake branch, release, updated. v3.10.0-32-g166bf4c

[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, release has been updated
   via  166bf4c490b8f46eca057fc23c3f3c2e042e9cb3 (commit)
  from  38b4209100f06f9f087e6e90368ff1df7854bbde (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:
 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

[Cmake-commits] CMake branch, master, updated. v3.10.0-627-ge80cc85

[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  e80cc856da6901338486d9183b527fbcbbe385dd (commit)
   via  166bf4c490b8f46eca057fc23c3f3c2e042e9cb3 (commit)
  from  3fdc4397e121f5125c103dc96e1e37b3e3454a5b (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=e80cc856da6901338486d9183b527fbcbbe385dd
commit e80cc856da6901338486d9183b527fbcbbe385dd
Merge: 3fdc439 166bf4c
Author: Brad King 
AuthorDate: Wed Dec 13 09:15:08 2017 -0500
Commit: Brad King 
CommitDate: Wed Dec 13 09:15:08 2017 -0500

Merge branch 'release-3.10'


---

Summary of changes:


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

Re: [CMake] Using CMake include does not seem to work intuatively

[Michael Jackson]

The way "include" was explained to me years ago was that it operates in much 
the same way as literally "pasting" all the code from the included file 
directly into the place where the include() command is used. With this in mind 
the "include(Bar.cmake)" from the Foo.cmake file and the associated error make 
sense. If you were to copy-paste the code from Foo.cmake into your 
CMakeLIsts.txt file then it would be looking for a Bar.cmake file in the same 
directory as "CMakeLists.txt". 

 

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

 

From: CMake  on behalf of Petr Kmoch 

Date: Wednesday, December 13, 2017 at 3:03 AM
To: Saad Khattak 
Cc: CMake Mail List 
Subject: Re: [CMake] Using CMake include does not seem to work intuatively

 

Hi Saad.

I can't comment on whether the behaviour is correct or expectable, but to get 
it working the way you want, you can specify the path fully:

include(${CMAKE_CURRENT_LIST_DIR}/Bar.cmake)

Petr

 

 

On 13 December 2017 at 01:34, Saad Khattak  wrote:

Hi,

 

Let's say I have the following directory structure:

~/Repos/MyRepo/CMakeLists.txt

~/CMakeFiles/Foo.cmake

~/CMakeFiles/Bar.cmake

 

In the CMakeLists.txt I have the following command:

 

include(~/CMakeFiles/Foo.cmake)

 

And in Foo.cmake I have the following command:

 

include(Bar.cmake)

 

Turns out that he `include(Bar.cmake)` from `Foo.cmake` fails. This is counter 
to what I would expect (e.g. how #include works in C).

 

Is this a bug or is this behavior expected? If it's expected, what is the 
workaround? We have a lot of common cmake files which in turn include files 
relative to each other and not the calling CMakeLists.txt.

 

Thank you,

Saad


--

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

-- 

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.0-625-g3fdc439

[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  3fdc4397e121f5125c103dc96e1e37b3e3454a5b (commit)
   via  38b4209100f06f9f087e6e90368ff1df7854bbde (commit)
   via  19d5969d37172d5332754968063267e9dbe1e171 (commit)
  from  a363c9356d60ea2cfdae7bd8a35b87cac463c4fc (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=3fdc4397e121f5125c103dc96e1e37b3e3454a5b
commit 3fdc4397e121f5125c103dc96e1e37b3e3454a5b
Merge: a363c93 38b4209
Author: Brad King 
AuthorDate: Wed Dec 13 08:03:05 2017 -0500
Commit: Brad King 
CommitDate: Wed Dec 13 08:03:05 2017 -0500

Merge branch 'release-3.10'


---

Summary of changes:


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

[Cmake-commits] CMake branch, release, updated. v3.10.0-31-g38b4209

[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, release has been updated
   via  38b4209100f06f9f087e6e90368ff1df7854bbde (commit)
   via  19d5969d37172d5332754968063267e9dbe1e171 (commit)
   via  4dae55fb70de42c2b55676f78ea7f0c6c8ad51b4 (commit)
   via  d1d8719f623fe570142c67bf8d54c43f31355262 (commit)
  from  e2303b257c0453033571ec20a767e9ab22308e8b (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/FindMPI.cmake|  289 +++---
 Modules/InstallRequiredSystemLibraries.cmake |9 +-
 2 files changed, 175 insertions(+), 123 deletions(-)


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

[Cmake-commits] CMake branch, master, updated. v3.10.0-622-ga363c93

[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  a363c9356d60ea2cfdae7bd8a35b87cac463c4fc (commit)
   via  f0b3fab179d0ebad7e0bcc6e564d989f992bcb84 (commit)
   via  95e86eafd71928dbdcdcd135951a172891eb6189 (commit)
   via  3395aec7b8d8242d1eb6c18b57aa4cbab3e9c6bc (commit)
   via  372dc9b0879d36e4017122ab0e7c7fd63a0763d5 (commit)
   via  4dae55fb70de42c2b55676f78ea7f0c6c8ad51b4 (commit)
   via  d1d8719f623fe570142c67bf8d54c43f31355262 (commit)
   via  834d1878415fddb04b388b042dba7ce55a9a8a5d (commit)
   via  c6a83ecf1761eea8d0907ea9d8913fe56029a00d (commit)
   via  a6005371b05eff6104cd94848c610cd7af841ab6 (commit)
   via  362a1f336d29fb315db937dcce4dbd894bbffd2d (commit)
   via  c365a0787058e41f0e96f4dd2447cb71a17f7696 (commit)
   via  c62ffdcd4f6f638a7d57221528ffbe112887c1b4 (commit)
  from  c97734280f5e5f2eab588b7b9f177a8e7f19c042 (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=a363c9356d60ea2cfdae7bd8a35b87cac463c4fc
commit a363c9356d60ea2cfdae7bd8a35b87cac463c4fc
Merge: f0b3fab d1d8719
Author: Brad King 
AuthorDate: Wed Dec 13 12:51:34 2017 +
Commit: Kitware Robot 
CommitDate: Wed Dec 13 07:52:54 2017 -0500

Merge topic 'findmpi-builtin-fix'

d1d8719f FindMPI: Fix various legacy problems

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0b3fab179d0ebad7e0bcc6e564d989f992bcb84
commit f0b3fab179d0ebad7e0bcc6e564d989f992bcb84
Merge: 95e86ea 4dae55f
Author: Brad King 
AuthorDate: Wed Dec 13 12:50:46 2017 +
Commit: Kitware Robot 
CommitDate: Wed Dec 13 07:50:52 2017 -0500

Merge topic 'irsl-msvc-omp-fix'

4dae55fb IRSL: Fix MSVC variable deferencing

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95e86eafd71928dbdcdcd135951a172891eb6189
commit 95e86eafd71928dbdcdcd135951a172891eb6189
Merge: 3395aec a600537
Author: Brad King 
AuthorDate: Wed Dec 13 12:49:46 2017 +
Commit: Kitware Robot 
CommitDate: Wed Dec 13 07:50:02 2017 -0500

Merge topic 'FindPerlLibs-MacOS-failure'

a6005371 FindPerlLibs: Add support for MSYS and CYGWIN
362a1f33 FindPerlLibs: refactoring
c365a078 FindPerlLibs: fix MacOS failure

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3395aec7b8d8242d1eb6c18b57aa4cbab3e9c6bc
commit 3395aec7b8d8242d1eb6c18b57aa4cbab3e9c6bc
Merge: 372dc9b c62ffdc
Author: Brad King 
AuthorDate: Wed Dec 13 12:49:04 2017 +
Commit: Kitware Robot 
CommitDate: Wed Dec 13 07:49:18 2017 -0500

Merge topic 'use-std-string'

c62ffdcd cmIDEOptions: use std::string instead of const char*

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=372dc9b0879d36e4017122ab0e7c7fd63a0763d5
commit 372dc9b0879d36e4017122ab0e7c7fd63a0763d5
Merge: c977342 834d187
Author: Brad King 
AuthorDate: Wed Dec 13 12:48:13 2017 +
Commit: Kitware Robot 
CommitDate: Wed Dec 13 07:48:29 2017 -0500

Merge topic 'update-kwsys'

834d1878 Merge branch 'upstream-KWSys' into update-kwsys
c6a83ecf KWSys 2017-12-12 (3ba214b7)

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4dae55fb70de42c2b55676f78ea7f0c6c8ad51b4
commit 4dae55fb70de42c2b55676f78ea7f0c6c8ad51b4
Author: Christian Pfeiffer 
AuthorDate: Tue Dec 12 15:15:00 2017 +0100
Commit: Christian Pfeiffer 
CommitDate: Tue Dec 12 15:16:38 2017 +0100

IRSL: Fix MSVC variable deferencing

Fixes: #17529

diff --git a/Modules/InstallRequiredSystemLibraries.cmake 
b/Modules/InstallRequiredSystemLibraries.cmake
index 1ba4877..f62bd09 100644
--- a/Modules/InstallRequiredSystemLibraries.cmake
+++ b/Modules/InstallRequiredSystemLibraries.cmake
@@ -56,10 +56,13 @@
 #   Specify the :command:`install(PROGRAMS)` command ``COMPONENT``
 #   option.  If not specified, no such option will be used.
 
+cmake_policy(PUSH)
+cmake_policy(SET CMP0054 NEW) # if() quoted variables not dereferenced
+
 set(_IRSL_HAVE_Intel FALSE)
 set(_IRSL_HAVE_MSVC FALSE)
 

Re: [CMake] absolute library path, sorry for the question

[Mario Emmenlauer]

Dear Bo Zhou,

Thank you for your reply!! Your explanation is very helpful for writing
my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
that comes with the libraries. For example libtiff, turbojpeg, thrift,
and many others...

As an example, I build libtiff in the following way:
cmake ../$TIFFVERSION \
-Wno-dev \
-G"Unix Makefiles" \
-DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
-DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
-DCMAKE_BUILD_TYPE="Release" \
-DBUILD_SHARED_LIBS="ON" \
-Djpeg="ON" \
-DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
-DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
make VERBOSE="1" && make install

In the build log, I can see that cmake detects the jpeg library to be
'$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
instead of my thirdparty libjpeg.

So at some point between FindJPEG.cmake and the final Makefile, cmake
changed the JPEG_LIBRARIES variable from absolute to relative. And I can
not understand why or when this happens. The documentation also does not
help me, because it explains that this should happen 'if the full path is
not know or if the full path is one of the system library dirs' (see
https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
I override to use jpeg with a known, existing path that is not a system
library.

All the best,

   Mario




On 13.12.2017 11:12, Bo Zhou wrote:
> Hi
> 
> CMAKE_SKIP_RPATH usually is used for the shared module which might want to 
> have the customized distributed path such as within the application. According
> personal experience on POSIX systems (Linux, UNIX, OSX), always enable 
> CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final 
> distribution,
> (if needed) put shared libraries into the lib folder of distribution.
> 
> According your description, I'm not sure how did you pick up your library 
> into the application from CMake, usually we have to make sure the CMake 
> always chooses
> the libraries from 3rd-party directory not system or another places. In our 
> system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the
> folder which contains the all built libraries, then use HINTS and NAMES in 
> the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the
> pre-built libraries, so the linking should be okay.
> 
> If everything has no error, but just the application always picks up the 
> system's library not the 3rd-party libraries we prepared, one solution would 
> add
> another loader script for the application, from the loader script it appends 
> the local lib folder to LD_LIBRARY_PATH, then launch the actual application
> executable file. A lot of commercial application on Linux solve the similar 
> issue by this way.
> 
> Wish my reply is helpful.
> 
> Thank you very much.
> 
> On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer  > wrote:
> 
> 
> Dear cmake users,
> 
> I have found good documentation on the cmake wiki about RPATH and
> its different variables, and also on the mailing lists. But somehow
> it still does not add up for me. Can you please help?
> 
> I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
> amongst others. I build many standard libraries (like tiff and jpeg)
> into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
> them there. On newer Linux and Windows, cmake uses always the absolute
> path to those libraries, and everything works fine. But on older Linux
> like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
> library in the correct absolute thirdparty directory, and I can confirm
> this by printing the 'XXX_LIBRARIES' variable in the find script. But
> later the Makefile will link with '-lxxx' instead of the full path.
> This makes 'ld' use the system library instead!
> 
> I completely fail to understand at what point cmake changes XXX_LIBRARIES
> from an absolute path to '-lxxx', for example for libjpeg.
> 
> I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
> The only workaround I could find is to add the thirdparty directory to
> LDFLAGS. Then 'ld' will also find the correct library.
> 
> 
> Is this a bug, or an expected behavior? What parameters should I add
> when I invoke cmake so that it will always use libraries with their
> full path?
> 
> 
> Cheers,
> 
>     Mario Emmenlauer
> 
> 
> 
> PS: since I build thirdparty libraries, I prefer not to change their
> CMakeLists.txt but would rather prefer to set better cmake command line
> parameters.
> 

Re: [CMake] absolute library path, sorry for the question

[Bo Zhou]

Hi

CMAKE_SKIP_RPATH usually is used for the shared module which might want to
have the customized distributed path such as within the application.
According personal experience on POSIX systems (Linux, UNIX, OSX), always
enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the
final distribution, (if needed) put shared libraries into the lib folder of
distribution.

According your description, I'm not sure how did you pick up your library
into the application from CMake, usually we have to make sure the CMake
always chooses the libraries from 3rd-party directory not system or another
places. In our system, it has a variable THIRDPARTY_DIR for command
FIND_PATH() to locate the folder which contains the all built libraries,
then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to
locate the correct paths for the pre-built libraries, so the linking should
be okay.

If everything has no error, but just the application always picks up the
system's library not the 3rd-party libraries we prepared, one solution
would add another loader script for the application, from the loader script
it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual
application executable file. A lot of commercial application on Linux solve
the similar issue by this way.

Wish my reply is helpful.

Thank you very much.

On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer 
wrote:

>
> Dear cmake users,
>
> I have found good documentation on the cmake wiki about RPATH and
> its different variables, and also on the mailing lists. But somehow
> it still does not add up for me. Can you please help?
>
> I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
> amongst others. I build many standard libraries (like tiff and jpeg)
> into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
> them there. On newer Linux and Windows, cmake uses always the absolute
> path to those libraries, and everything works fine. But on older Linux
> like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
> library in the correct absolute thirdparty directory, and I can confirm
> this by printing the 'XXX_LIBRARIES' variable in the find script. But
> later the Makefile will link with '-lxxx' instead of the full path.
> This makes 'ld' use the system library instead!
>
> I completely fail to understand at what point cmake changes XXX_LIBRARIES
> from an absolute path to '-lxxx', for example for libjpeg.
>
> I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
> The only workaround I could find is to add the thirdparty directory to
> LDFLAGS. Then 'ld' will also find the correct library.
>
>
> Is this a bug, or an expected behavior? What parameters should I add
> when I invoke cmake so that it will always use libraries with their
> full path?
>
>
> Cheers,
>
> Mario Emmenlauer
>
>
>
> PS: since I build thirdparty libraries, I prefer not to change their
> CMakeLists.txt but would rather prefer to set better cmake command line
> parameters.
>
>
> References:
> https://cmake.org/Wiki/CMake_RPATH_handling
> https://cmake.org/pipermail/cmake/2015-September/061462.html
>
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
> --
>
> 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] absolute library path, sorry for the question

[Mario Emmenlauer]

Dear cmake users,

I have found good documentation on the cmake wiki about RPATH and
its different variables, and also on the mailing lists. But somehow
it still does not add up for me. Can you please help?

I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
amongst others. I build many standard libraries (like tiff and jpeg)
into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
them there. On newer Linux and Windows, cmake uses always the absolute
path to those libraries, and everything works fine. But on older Linux
like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
library in the correct absolute thirdparty directory, and I can confirm
this by printing the 'XXX_LIBRARIES' variable in the find script. But
later the Makefile will link with '-lxxx' instead of the full path.
This makes 'ld' use the system library instead!

I completely fail to understand at what point cmake changes XXX_LIBRARIES
from an absolute path to '-lxxx', for example for libjpeg.

I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
The only workaround I could find is to add the thirdparty directory to
LDFLAGS. Then 'ld' will also find the correct library.


Is this a bug, or an expected behavior? What parameters should I add
when I invoke cmake so that it will always use libraries with their
full path?


Cheers,

Mario Emmenlauer



PS: since I build thirdparty libraries, I prefer not to change their
CMakeLists.txt but would rather prefer to set better cmake command line
parameters.


References:
https://cmake.org/Wiki/CMake_RPATH_handling
https://cmake.org/pipermail/cmake/2015-September/061462.html



--
BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
D-81669 München  http://www.biodataanalysis.de/
-- 

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 CMake include does not seem to work intuatively

[Petr Kmoch]

Hi Saad.

I can't comment on whether the behaviour is correct or expectable, but to
get it working the way you want, you can specify the path fully:

include(${CMAKE_CURRENT_LIST_DIR}/Bar.cmake)

Petr


On 13 December 2017 at 01:34, Saad Khattak  wrote:

> Hi,
>
> Let's say I have the following directory structure:
> ~/Repos/MyRepo/CMakeLists.txt
> ~/CMakeFiles/Foo.cmake
> ~/CMakeFiles/Bar.cmake
>
> In the CMakeLists.txt I have the following command:
>
> include(~/CMakeFiles/Foo.cmake)
>
> And in Foo.cmake I have the following command:
>
> include(Bar.cmake)
>
> Turns out that he `include(Bar.cmake)` from `Foo.cmake` fails. This is
> counter to what I would expect (e.g. how #include works in C).
>
> Is this a bug or is this behavior expected? If it's expected, what is the
> workaround? We have a lot of common cmake files which in turn include files
> relative to each other and not the calling CMakeLists.txt.
>
> Thank you,
> Saad
>
> --
>
> 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