Re: [CMake] Install rpath handling for iOS frameworks [solved-ish]
It looks like you want the default behavior, but from what you show,
I don't know what is disabling it. The default behavior does not require
you to set the XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME, nor does it require you
to call install_name_tool yourself at install time to get @rpath.
Not getting @rpath could be from the old behavior of CMP0042,
setting MACOSX_RPATH = 0, or setting INSTALL_NAME_DIR = "".
I think those are the only 3 factors, but in older versions of CMake, before
CMP0068,
there were more variables which could affect it.
If you are doing cross compiling with a toolchain file, maybe its something
else,
such as the setting of CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG.
Clint
- On Oct 20, 2017, at 2:40 AM, Robert Bielik robert.bie...@dirac.com wrote:
> Ok, this is most certainly not the way to do it, but I added two install
> steps:
>
> install(CODE "SET(FRAMEWORK_SO \"dummy.framework/dummy\")")
> install(SCRIPT add_rpath.cmake COMPONENT frameworks)
>
> add_rpath.cmake:
>
> # Adds @rpath to the SO in the framework because CMake install removes it
> (!!!)
> EXECUTE_PROCESS(
>COMMAND install_name_tool -id "@rpath/${FRAMEWORK_SO}" ${FRAMEWORK_SO}
>WORKING_DIRECTORY ${CMAKE_INSTALL_PREFIX}
> )
> #
>
> And this works with install target and packaging. But it is ugly.
> /R
>
>> -Original Message-
>> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert
>> Bielik
>> Sent: den 20 oktober 2017 08:32
>> To: Cmake@cmake.org
>> Subject: Re: [CMake] Install rpath handling for iOS frameworks
>>
>> Running 3.9.4 I see that behavior related to RPATH on macOS has changed:
>>
>> https://cmake.org/cmake/help/v3.9/policy/CMP0068.html
>>
>> I've tried setting the policy to OLD, but I'm just not able to get
>> @rpath/... to
>> propagate to the install ☹
>>
>> Ideas, please ?
>> /R
>>
>> > -Original Message-
>> > From: Robert Bielik
>> > Sent: den 19 oktober 2017 16:14
>> > To: Robert Bielik ; Cmake@cmake.org
>> > Subject: RE: Install rpath handling for iOS frameworks
>> >
>> > Oh, and I just added:
>> >
>> > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
>> >
>> > But it doesn't change anything.
>> >
>> > /R
>> >
>> > > -Original Message-
>> > > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert
>> > > Bielik
>> > > Sent: den 19 oktober 2017 16:09
>> > > To: Cmake@cmake.org
>> > > Subject: [CMake] Install rpath handling for iOS frameworks
>> > >
>> > > I'm trying to package an iOS framework, and with the target setting:
>> > >
>> > > XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME
>> > > "@rpath/$(EXECUTABLE_PATH)"
>> > >
>> > > I get the framework built nicely. otool -L dummy.framework/dummy
>> > shows
>> > >
>> > >@rpath/dummy.framework/dummy
>> > >
>> > > Just as it should. Now I have a install directive:
>> > >
>> > > install(TARGETS dummy
>> > > FRAMEWORK DESTINATION "./" COMPONENTS frameworks)
>> > >
>> > > Then I do cpack -G ZIP, and it all packages together without a hitch.
>> > > But when I do otool -L of the dummy.framework/dummy from where
>> the
>> > > package is built I get:
>> > >
>> > >dummy.framework/dummy
>> > >
>> > > i.e. @rpath has been removed during the install process ?
>> > >
>> > > What am I doing wrong ?
>> > >
>> > > TIA
>> > > /Robert
>> > >
>> > > --
>> > >
>> > > 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
Re: [CMake] OSX RPATH linker flags not added on first build
- On Feb 3, 2017, at 11:25 AM, Doug Digglington
wrote:
> Hello,
> I am using ExternalProject to download and build a third-party library (SDL)
> in
> my project. I am running into an issue on OSX where the RPATH linker flags
> will
> not be added when my project is built and linked for the first time. As a
> result the built executable will not have any RPATH paths in it. However, when
> I rerun CMake or touch the main CMakeLists.txt file and rebuild then the
> linker
> flags will be added appropriately.
> I have tried explicitly setting the RPATH variables according to the "CMake
> RPATH handling" page both for the default and "always full" scenarios but that
> did not seem to change this behavior. Here is my current CMakeLists.txt file:
> cmake_minimum_required(VERSION 3.5)
> project(shared_object)
> set(CMAKE_MACOSX_RPATH TRUE)
> set(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/sdl/install)
> set(LIB_DIR ${LIB_INSTALL_DIR}/lib)
> set(LIB_PATH
> ${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}SDL2${CMAKE_SHARED_LIBRARY_SUFFIX})
> include(ExternalProject)
> ExternalProject_Add(
> libsdl
> PREFIX ${CMAKE_BINARY_DIR}/sdl
> URL [ https://www.libsdl.org/release/SDL2-2.0.5.tar.gz |
> https://www.libsdl.org/release/SDL2-2.0.5.tar.gz ]
> URL_MD5 d4055424d556b4a908aa76fad63abd3c
> CMAKE_ARGS
> -DCMAKE_INSTALL_PREFIX=${LIB_INSTALL_DIR}
> -DCMAKE_MACOSX_RPATH=${CMAKE_MACOSX_RPATH}
> -DSDL_STATIC=FALSE
> INSTALL_DIR ${LIB_INSTALL_DIR}
> )
> add_library(sdl SHARED IMPORTED GLOBAL)
> set_target_properties(sdl PROPERTIES
> IMPORTED_LOCATION ${LIB_PATH}
> )
You could try adding another property here.
set_target_properties(sdl PROPERTIES IMPORTED_SONAME "@rpath/
${CMAKE_SHARED_LIBRARY_PREFIX}SDL2${CMAKE_SHARED_LIBRARY_SUFFIX}")
With that hint, CMake would not need to wait until the library exists before
being able to find out if it uses @rpath.
And I see you also set CMAKE_MACOSX_RPATH=TRUE. That will only have an effect
on any add_library() calls within the current scope (excluding imported
libraries).
Clint
> add_dependencies(sdl libsdl)
> add_executable(shared_object main.cpp)
> target_link_libraries(shared_object sdl)
> When I run CMake for the first time here are the contents of the
> CMakeFiles/shared_object.dir/link.txt file:
> /Applications/Xcode_6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> CMakeFiles/shared_object.dir/main.cpp.o -o shared_object
> sdl/install/lib/libSDL2.dylib
> Notice that there are no -Wl,-rpath linker flags. When I run `make` to build
> the
> project there is no RPATH information in the built executable. I checked this
> with `otool -l shared_object | grep -A2 RPATH`.
> Now if I rerun CMake after everything has been built or if I touch the
> CMakeLists.txt file before running `make` again then the contents of the
> CMakeFiles/shared_object.dir/link.txt changes and the RPATH information is
> linked into the built application. Here is the contents of
> CMakeFiles/shared_object.dir/link.txt after I rerun CMake:
> /Applications/Xcode_6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> CMakeFiles/shared_object.dir/main.cpp.o -o shared_object
> -Wl,-rpath,/var/tmp/so/sdl/install/lib sdl/install/lib/libSDL2.dylib
> After rebuliding the application it will contain the expected RPATH
> information:
> otool -l shared_object | grep -A2 RPATH
> cmd LC_RPATH
> cmdsize 40
> path /var/tmp/so/sdl/install/lib (offset 12)
> Is there something that I am configuring incorrectly about the external
> project
> or imported library that causes it to not be known or added to the linker
> flags
> the first time CMake is run?
> --
> 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/unsubscrib
Re: [CMake] How to use a generated linker map with a shared library?
On Jan 14, 2017 7:16 PM, Paul Smith wrote:On Sun, 2017-01-15 at 12:08 +1100, Craig Scott wrote: > While not directly answering your question, it seems you may be trying > to deal with symbol visibility. Are you aware of CMake's symbol > visibility features? A good place to start would be the > GenerateExportHeader module, the documentation for which does a > reasonable job of showing how to use the visibility features CMake > provides. Yes, thanks for that info. My situation is that I need to force ALL symbols to be private, even those from external static shared libraries that I'm linking in (whose symbols have global visibility by default). Have you tried the "--exclude-libs ALL" linker option? Using that should hide symbols from static libraries.Clint-- 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] Full absolute path as RPATH in build tree
If you want the INSTALL_NAME_DIR to have effect in the build tree, you also need
set_target_properties(EMsoftLib PROPERTIES BUILD_WITH_INSTALL_RPATH ON)
Clint
- On Dec 5, 2016, at 8:22 PM, Michael Jackson mike.jack...@bluequartz.net
wrote:
> I have this:
>
> if(APPLE AND BUILD_SHARED_LIBS)
> set_target_properties(EMsoftLib PROPERTIES MACOSX_RPATH FALSE)
> set_target_properties(EMsoftLib PROPERTIES INSTALL_NAME_DIR
> "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}")
> endif()
>
> --
> Michael A. Jackson 400 S. Pioneer Blvd
> Owner, President Springboro, Ohio 45066
> BlueQuartz Software, LLC EMail: mike.jack...@bluequartz.net
> Voice: 937-790-1601Web: http://www.bluequartz.net
> Fax: 937-746-0783
>
>
> clin...@elemtech.com wrote:
>> Do you want the library identification to be a full path?
>> set_target_properties(foo PROPERTIES MACOSX_RPATH OFF)
>>
>> Clint
>>
>> - On Dec 5, 2016, at 7:38 PM, Michael Jackson mike.jack...@bluequartz.net
>> wrote:
>>
>>> what combinations of RPATH variables do I need to set to get a full,
>>> absolute path to a build library in my build tree? THis is on macOS
>>> 10.10.5 and cmake 3.5 and above. I have tried all sorts of combinations
>>> and I either get just the library name or @rpath/library.dylib neither
>>> of which is going to work for my needs.
>>>
>>> Thanks
>>>
>>> --
>>> Michael A. Jackson
>>> BlueQuartz Software, LLC
>>> [e]: mike.jack...@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:
> >> 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
Re: [CMake] Full absolute path as RPATH in build tree
Do you want the library identification to be a full path? set_target_properties(foo PROPERTIES MACOSX_RPATH OFF) Clint - On Dec 5, 2016, at 7:38 PM, Michael Jackson mike.jack...@bluequartz.net wrote: > what combinations of RPATH variables do I need to set to get a full, > absolute path to a build library in my build tree? THis is on macOS > 10.10.5 and cmake 3.5 and above. I have tried all sorts of combinations > and I either get just the library name or @rpath/library.dylib neither > of which is going to work for my needs. > > Thanks > > -- > Michael A. Jackson > BlueQuartz Software, LLC > [e]: mike.jack...@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: > 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
Re: [CMake] Force MSVC runtime for debug builds
- On Nov 7, 2016, at 1:37 AM, Stephan Menzel wrote: > Hello everyone, > I'm looking for a way to force Debug configurations in generated MSVC > solutions > to use the Release runtime instead of the default "Debug". e.g. /MD rather > than > /MDd. > My use case is an ever recurring problem of creating libraries that are linked > in plug-in fashion against Release only applications. I want for my Debug > configuration to have debug info and no optimization but still use the release > runtime so I can link them. > I tried replacing /MDd with /MD in CMAKE_CXX_FLAGS_DEBUG. This yielded objects > built with /MD alright but failed to link into an executable with stuff like > that: > error LNK2038: mismatch detected for 'RuntimeLibrary': value > 'MD_DynamicRelease' > doesn't match value 'MDd_DynamicDebug' in Test.obj > From what I gather all the obj are actually compiled for Release runtime > without > optimization and Debug info just like I need it. But then the main obj is > built > and linked in Debug mode, causing the executable to not be created. > Is there a way to solve this? Like a generic CMake executable flag or > something > that I can use to force the other runtime? > Please note that using RelWithDebInfo and turning off optimization is not > exactly what I need as I still want that mode much the way it is. If you are going to use /MD instead of /MDd, then you probably also need to remove the _DEBUG preprocessor flag. IIRC, I've seen cases where defining _DEBUG includes symbols only defined by the debug runtimes. Clint -- 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 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio
- On Nov 8, 2016, at 8:13 AM, Taylor Braun-Jones tay...@braun-jones.org
wrote:
> On Fri, Nov 4, 2016 at 2:55 PM, Brad King wrote:
>>
>> On 11/03/2016 06:04 PM, John Drescher wrote:
>> > I opened a project in cmake-gui using the open project button from a
>> > vc 2010 build of a project. The open project opened the project in
>> > Visual Studio 2010. Later I opened the same project but a different
>> > build tree for Visual Studio 2013 CMake-gui had all of the correct
>> > information for the Visual Studio 2013 build but open project tried to
>> > open the Visual Studio 2013 solution in Visual Studio 2010 instead of
>> > the expected Visual Studio 2013.
I'm unable to reproduce this problem. I have multiple Visual Studio
installations of different versions.
I'm not sure whether it could be specific to a project, or specific to
installations of visual studio.
>
> I'm guessing you established MSVS2010 as the default application for
> opening .sln files the first time you used the open project button.
> What happens if you double click on that MSVS2013 .sln file?
>
>> The feature is new in 3.7 and was contributed here:
>>
>> cmake-gui: Add button to open the generated project
>> https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1
>>
>> I'm not particularly familiar with how it works, but from a quick
>> glance at the code it may be using file associations.
>
> Yes, it's just using Windows file file associations, but it shouldn't.
> Since it's possible (and fairly common) to have more than one version
> of Visual Studio installed on a system the Open Project button should
> be smarter and use ${CMAKE_VS_DEVENV_COMMAND} to open the .sln file.
> It should be something like this:
>
> MSVS2015: %VS140COMNTOOLS%..\IDE\devenv.com
> MSVS2013: %VS120COMNTOOLS%..\IDE\devenv.com
> MSVS2012: %VS110COMNTOOLS%..\IDE\devenv.com
> MSVS2010: %VS100COMNTOOLS%..\IDE\devenv.com
>
> If the correct devenv.exe path does not exist or can't be determined
> for some reason, then I guess it makes sense to fall back to using
> `QDesktopServices::openUrl` to try to open the .sln file with the
> Windows file associations.
It is already using QDesktopServices::openUrl(QUrl::fromLocalFile(...))
AFAIK, that is the correct way to do it. The .sln file should already know
what version of Visual Studio it wants to be opened in.
Clint
--
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] Browse buttons in CMake-Gui give URL cannot be listed Malformed URL error (Manjaro KDE Plasma 5.7 Qt 5.7)
- On Sep 20, 2016, at 4:18 PM, cmake wrote: > Hi. > When I click "Browse source" or "Browse build" location buttons in the GUI I > get > an error dialog saying that "URL cannot be listed file://" followed by another > dialog "Malformed URL". > 1. I built and reinstalled CMake from source but the problem persists. > 2. I searched the web but could not find anyone reporting this issue for > CMake. >3. When I launch CMake-gui from terminal, when I click the Browse buttons > it >prints "kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to > find >"file"" in the terminal. I tried looking up for this message but again I > could > not find anything about CMake. > Please let me know if you need some logs. > Machine: x64, Manjaro KDE Plasma 5.7, Qt 5.7 Nvidia GTX 960m, i7-6700 HQ > Regards, > Amit Hi Amit, This should fix your problem. Can you verify? https://cmake.org/gitweb?p=cmake.git;a=commit;h=48624b3c Thanks, Clint -- 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] Browse buttons in CMake-Gui give URL cannot be listed Malformed URL error (Manjaro KDE Plasma 5.7 Qt 5.7)
Hi, Thanks for reporting this. I was also able to reproduce it. The problem comes from cmake-gui calling QApplication::removeLibraryPath() in CMakeSetup.cxx. I think the solution is to remove that bit of code, but it may require some additional cpack related code to handle plugins correctly. It appears we are doing that cpack code for Windows and Mac already, but not for Linux (see CMake/Source/QtDialog/CMakeLists.txt line 48 to 85). Clint - On Sep 20, 2016, at 4:18 PM, cmake wrote: > Hi. > When I click "Browse source" or "Browse build" location buttons in the GUI I > get > an error dialog saying that "URL cannot be listed file://" followed by another > dialog "Malformed URL". > 1. I built and reinstalled CMake from source but the problem persists. > 2. I searched the web but could not find anyone reporting this issue for > CMake. >3. When I launch CMake-gui from terminal, when I click the Browse buttons > it >prints "kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to > find >"file"" in the terminal. I tried looking up for this message but again I > could > not find anything about CMake. > Please let me know if you need some logs. > Machine: x64, Manjaro KDE Plasma 5.7, Qt 5.7 Nvidia GTX 960m, i7-6700 HQ > Regards, > Amit > -- > 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
Re: [CMake] works when I build using XCode, but not with CMake makefile
- On Sep 7, 2016, at 12:52 PM, Cotton Candy wrote: > Here is the output from otool -L on skedmo-solver that you requested: > skedmo-solver: > libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1197.1.1) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) > on /usr/lib/libmysqlclient.18.dylib I get an error > aaron-schurgers-computer-3:lib schurger$ otool -L libmysqlclient.18.dylib > error: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: > can't open file: libmysqlclient.18.dylib (No such file or directory) > even though the file libmysqlclient.18.dylib is clearly there when I do ls Try doing "ls -l" Perhaps its a softlink to a file which doesn't exist. Clint -- 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] works when I build using XCode, but not with CMake makefile
It may help to include the output of "otool -L" on skedmo-solver, /usr/lib/libmysqlclient.18.dylib and /Applications/MAMP/Library/lib/libmysqlclient.18.dylib. And it may also help to see if there is a difference in the otool output in the Xcode vs makefile scenario. Also, it may help to check the output of "otool -l skedmo-solver" for both the Xcode and makefile scenario. Clint - On Sep 7, 2016, at 5:18 AM, Cotton Candy wrote: > Hi Peter, > I attach my CMakeLists.txt file as well as the FindMySQL.cmake finder that I > used, in case these help. > I still get the same error when I run the executable: > dyld: Library not loaded: libmysqlclient.18.dylib > Referenced from: /Users/schurger/tmp/test_CMake2/./skedmo-solver > Reason: image not found > Trace/BPT trap: 5 > This library (libmysqlclient.18.dylib) is in /usr/lib on my machine. > Thanks for all your help. > Aaron > On Wed, Sep 7, 2016 at 9:36 AM, Peter Steinbach < steinb...@scionics.de > > wrote: >> Hi Mr Candy (I am still getting a heck out of cottoncandycoder, sorry :D ) >> 1) the way you do it, is not really the way cmake should be used AFAIK. >> > In my CMakeLists.txt file I included: >> > set( CMAKE_CXX_FLAGS "-L/Applications/MAMP/Library/lib -lmysqlclient >> > -lpthread -lz" ) >> > set( CMAKE_EXE_LINKER_FLAGS "-lmysqlclient -lpthread -lm -lz" ) >> change this to: >> #I assume you have something like this somewhere >> add_executable(my_exe_name SOURCES my_exe_name.???) >> #here comes the "magic" >> link_directories(/Applications/MAMP/Library/lib) >> target_link_libraries(mysqlclient pthread m z) >> In theory, if all those dependencies are available at cmake-invocation, this >> should emit compiler calls that produce your binary and link mysqlclient into >> it (by default with using RPATH, see the docs on this: >> https://cmake.org/cmake/help/v3.0/prop_tgt/MACOSX_RPATH.html#prop_tgt:MACOSX_RPATH >> ). Depending on whether you wanna distribute your binary and cannot be sure >> if >> (at build time) pthreads etc are available, there are cmake find modules for >> pthreads and libz (FindThreads, FindZLIB) which you can use. libm should come >> with the libc of the system AFAIK. >> I also just checked but up to cmake 3.5, there is no MYSQL Find module. >> Which is >> kinda sad as there is a FindPostgreSQL module. :( If there would be, you >> could >> use it in a (hopefully) platform independent way and not bother with finding >> the right paths to libmysqlclient. >> 2) The compiler flags you posted do not explain, why Xcode apparently sets >> the >> rpath inside the binary and your cmake script doesn't (haven't seen the full >> CMakeLists.txt of your project yet). >> I hope the above gets you going. >> @cmake developers: it would be nice to have more obvious pointers to cmake >> example projects like an example SDK or so. If there is, please let me know. >> I >> only found this: >> http://www.vtk.org/Wiki/CMake/Examples#Finding_Packages >> but that's tied to vtk. >> Best, >> peter >> On 09/06/2016 08:12 PM, Cotton Candy wrote: >> > Peter, >> > In XCode I have this list of "settings" that includes >> > "Other Linker Flags" that I have set to "-lmysqlclient -lpthread -lm -lz" >> > and >> > "Other C++ Flags" that I have set to "-L/Applications/MAMP/Library/lib >> > -lmysqlclient -lpthread -lz" >> > Maybe these explain why things work when I build with XCode, but not with >> > CMake. >> > but when I run the make it always says it is ignoring these (e.g. "warning: >> > argument unused during compilation: '-L/Applications/MAMP/Library/lib'"). >> > Thanks again for you help. >> > Aaron >> > On Tue, Sep 6, 2016 at 2:20 PM, Peter Steinbach < steinb...@scionics.de > >> > wrote: >> >> Aaron, >> >> it's about the way that you compile your binary and link libmysqlclient >> >> into it. I guess (@all: please correct me if I am wrong) as I don't know >> >> how you use cmake to build your libraries/binaries, that you don't set the >> >> rpath of libmysqlclient inside your binary. Doing so will ensure that the >> >> absolute path of libmysqlclient is stored into your binary, so that the >> >> runtime environment can pick it up and use (keeping fingers crossed that >> >> the path is still valid). The alternative to doing so, is linking against >> >> the static version of libmysqlclient (which comes at a cost on another >> >> front as well). >> >> Best, >> >> P > -- > 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 su
Re: [CMake] CPack: Combine Debug and Release build
One thing I've done before is to tell cpack to bundle up 2 projects in one
cpack session.
One project is a debug build, and the other a release build.
if ( CREATE_MULTI_CONFIG_PACKAGE )
set (CPACK_INSTALL_CMAKE_PROJECTS
# self project
" ${CMAKE_CURRENT_BINARY_DIR} ; ${CMAKE_PROJECT_NAME} ;ALL;/"
# other project
" ${DIR_TO_OTHER_PROJECT} ; ${CMAKE_PROJECT_NAME} ;ALL;/"
)
endif ()
- On Aug 18, 2016, at 5:12 AM, tonka tonka wrote:
> Hey,
> I want to switch to cpack to build my zip, installer etc.. Everything works
> fine, but I am not able to get my debug build into my cpack end file. It will
> always use the release build, which is fine for end-user deployment but not
> for
> and sdk installer, because on windows I have to provide both
> build-configurations.
> Can anybody give me some advice what I can do to get such result?
> Thanks in advance
> Tonka
> --
> 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
Re: [CMake] Recommended style for multiple CPack generator folder structures
I prefer one for both installing and creating packages. install(TARGETS bar COMPONENT bar DESTINATION "./" # This must be "./" not "/" as it has to be a relative path ) Then set CMAKE_PREFIX_PATH=/Applications/Foo when you do an install. CMAKE_PREFIX_PATH will be pre-pended to relative paths given in install() commands. Clint - On May 24, 2016, at 5:40 AM, Harry Mallon ha...@codexdigital.com wrote: > In answer to my own question. One way to do it which seems quite neat is as > follows. Using multiple installs: > > install(TARGETS bar >COMPONENT bar >DESTINATION "Applications/Foo" > ) > > install(TARGETS bar >COMPONENT bar-standalone >DESTINATION "./" # This must be "./" not "/" as it has to be a relative > path > ) > > This in your CPACK_PROJECT_CONFIG_FILE: > > if (CPACK_GENERATOR STREQUAL DragNDrop) >set(CPACK_COMPONENTS_ALL bar-standalone) > endif() > > Harry > > Harry Mallon > CODEX | Software Engineer > 60 Poland Street | London | England | W1F 7NT > E ha...@codexdigital.com | T +44 203 7000 989 > -- > > 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
Re: [CMake] Install with full absolute path on OS X
To set the install name to an absolute path, it would probably be something
like
set_property(TARGET EMsoft PROPERTY INSTALL_NAME_DIR
${CMAKE_INSTALL_PREFIX}/lib)
Clint
- On Apr 26, 2016, at 12:24 PM, Michael Jackson
wrote:
> I am building a library and installing onto the local system. After
> installation
> otool reports that the path is "@rpath/lib/libEMsoft.dylib"
> How can I have the installed path be the full absolute path to the library.
> For
> this use case @rpath is not going to work.
> I have tried https://cmake.org/Wiki/CMake_RPATH_handling and variations of
> that
> information but none of it seems to work.
> THanks
> --
> Mike Jackson [ mike.jack...@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:
> 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
Re: [CMake] CPack and PackageMaker
Hi, I have updated the patch I sent before and you can find some new code here: https://github.com/clintonstimpson/CMake/commits/productbuild To help, perhaps you can review and test it. Or help in other ways you think it needs. I have done minimal testing. This includes making sure CMake's test suite passes with this generator. And running those generated pkg files manually to test them. Perhaps after a couple reviews, we can start thinking about merging into CMake. Thanks, Clint - On Dec 21, 2015, at 11:56 PM, Roman Wüger wrote: > Is there anything I can do to support? > Best regards > Am 11.12.2015 um 20:17 schrieb robert.bielik < robert.bie...@dirac.se >: >> Dear Clint, >> Thank you! Will certainly start with that as a base :) >> Regards >> /R >> -- Ursprungligt meddelande-- >> Från: >> Datum: fre, 11 dec 2015 20:12 >> Till: Robert Bielik; >> Kopia: Attila Krasznahorkay;cmake; >> Ämne: Re: [CMake] CPack and PackageMaker >> If you are interested, attached is some code I started a couple years ago but >> never finished, nor did I do much testing. >> Perhaps that'll help, or maybe you'll find a better way. >> Clint >> - On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bie...@dirac.se >> wrote: >> > Dear Attila, >> > Ok, been struggling getting an installation package to work with the >> > pkgbuild/productbild tools, so I think I got the gist of what needs to >> > be done, at least to get something going :) >> > Regards >> > /R >> > Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay: >> >> Hi Robert, >> >> I'm afraid that the sad situation is that nobody has done this yet, or is >> >> working on it at the moment. >> >> I'm absolutely sure that if you can help with this by any amount, that >> >> will be >> >> most welcome by the CMake developers. It will certainly be most welcome >> >> by me, >> >> as I've been disappointed by the lack of this support as well. (But >> >> unfortunately can't spare the time to help out in writing this CPack >> >> generator.) >> >> Cheers, >> >> Attila >> >>> On 11 Dec 2015, at 17:44, Robert Bielik wrote: >> >>> Really ? No one ? :) >> >>> So it's ok to go ahead and start create a new one ? ;) >> >>> Rgds, >> >>> /R >> >>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik: >> Mac OSX: >> Since PackageMaker has been deprecated by Apple, the new tools to use >> are >> pkgbuild [1] and productbuild [2]. >> Simple question: Is there any work being done by the CMake community on >> a new OS >> X CPack backend to support the above tools ? >> Regards >> /Robert >> [1] >> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html >> [2] >> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html >> >> >>> -- >> >>> 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/cmak
Re: [CMake] shared library versioning on OS X
Perhaps this bug report fits what you are seeing. Are you seeing this limitation in the ninja generator? https://cmake.org/Bug/view.php?id=14140 Clint On Feb 20, 2016 11:49 AM, Bruce Stephens wrote: > > By the looks of it setting the SOVERSION when generating a SHARED library > creates the symbolic link, but it doesn't seem to use the -current_version or > -compatibility_version flags when linking. > > Those flags are set as variables CMAKE_C_OSX_CURRENT_VERSION_FLAG and > CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages) but > those don't seem to be used. > > Is that deliberate? > -- 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_INSTALL_RPATH_USE_LINK_PATH is broken?
On Jan 8, 2016 8:16 PM, Elizabeth Fischer wrote: > > Hello, > > I'm using cmake 3.4.1. I'm trying to compile libraries & executables with an > RPATH. To that end, I use the following settings: >> >> >> SET(CMAKE_SKIP_BUILD_RPATH FALSE) >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) >> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > > I then link in a lot of libraries. However, ONLY ONE of the libraries gets > picked up to be used in the RPATH sent to the linker. I can manually set > CMAKE_INSTALL_RPATH (that works). But CMAKE_INSTALL_RPATH_USE_LINK_PATH > seems to be broken. > > Interestingly, the one library it's willing to auto-generate an RPATH for is > the same library, whether it comes first or last in the link command line. > The link command generated by CMake is shown below; it's clear that many > libraries are being linked in, but only one rpath is being generated. Did you check that the libraries you are linking against have an install name starting with @rpath? For example, otool -D /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib CMake will only consider adding an rpath for a library if the install name starts with @rpath. Clint > > HELP? > --- Elizabeth > >> [ 30%] Linking CXX executable test_array >> >> cd /Users/rpfische/git/spsparse/build/test && >> /Users/rpfische/macports/mpgompi-4.9.3/bin/cmake -E cmake_link_script >> CMakeFiles/test_array.dir/link.txt --verbose=1 >> >> /Users/rpfische/macports/mpgompi-4.9.3/bin/g++ -g -Wl,-search_paths_first >> -Wl,-headerpad_max_install_names CMakeFiles/test_array.dir/test_array.cpp.o >> -o test_array >> /Users/rpfische/eb/software/gtest/1.7.0-GCC-4.9.3/lib/libgtest.a >> /Users/rpfische/eb/software/gtest/1.7.0-GCC-4.9.3/lib/libgtest_main.a >> /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib >> /Users/rpfische/eb/software/netCDF-C++4/ecdf914-mpgompi-4.9.3/lib/libnetcdf-cxx4.dylib >> /Users/rpfische/eb/software/ibmisc/devel/lib/libibmisc.dylib >> ../slib/libspsparse.dylib >> /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib >> /Users/rpfische/eb/software/netCDF-C++4/ecdf914-mpgompi-4.9.3/lib/libnetcdf-cxx4.dylib >> /Users/rpfische/eb/software/ibmisc/devel/lib/libibmisc.dylib >> -Wl,-rpath,/Users/rpfische/eb/software/ibmisc/devel/lib -- 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] still having rpath problems on osxZ
- On Dec 31, 2015, at 1:41 AM, Boudewijn Rempt b...@valdyas.org wrote: > I think I've finally figured out why I didn't get the results the cmake > documentation suggested I should be getting... It's the extra-cmake-modules > that I use, Krita being a KDE application. With these settings: > > set(KDE_SKIP_RPATH_SETTINGS 1) > set(CMAKE_MACOSX_RPATH 1) > set(BUILD_WITH_INSTALL_RPATH 1) > > My libraries are built with an @rpath id, instead of an absolute path id. Now > only the executable needs to have its rpath set correctly after install and > after making a bundle, and all libraries are found and all plugins find the > libraries, too. > > Without KDE_SKIP_RPATH_SETTINGS, everything gets set to full, absolute paths > on > doing a make install. That might make sense on Linux, I guess... But no wonder > that I was confused all the time. > > So, to check that I really understand it: > > On OSX, every library has an id. That id can be > /abs/o/lute/path/to/library.dylib or library.dylib or @rpath/library.dylib. Yes, there is an id. @executable_path and @loader_path are a couple other that can used in addition to the list you provided. > > The exectutable has a bunch of paths where it can look for libraries, and the > path + library.dylib has to match the library id. I'm not sure what you mean by that. The library id is used only at link time, and not at runtime. There is no matching to the library id at runtime. At link time, the id is taken as-is and put into the executable as a dependency. If you are familiar with SONAME on ELF platforms, think of the id in a dylib being similar. > > so, if the executable has > > @path = ../lib;../Frameworks > > and links to > > @path/library.dylib > > and a library with that id is in ../lib (or ../Frameworks) from the > executable's > location, everything will be fine. I think you have the idea there. But just in case, let me enumerate how the runtime loader looks at these: 1. an exectuable with a /absolute/path/to/library.dylib dependency The library is searched for at the absolute path. If not found, library.dylib is searched in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 2. an executable with a library.dylib dependency library.dylib is searched in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 3. a binary with a @executable_path/library.dylib dependency The library is located in the same directory as the executable If the binary is another shared library, whether in another directory or not, library.dylib will be searched for in the same directory as the executable. If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. both exectuables and libraries can have @executable_path 3. a binary with @loader_path/library.dylib dependency the library is located in the same directory as the binary (may be the same directory as the executable or not). If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 4. a binary with @rpath/library.dylib dependency the binary can also have a list of rpaths embedded. Each rpath is used to replace the "@rpath" portion of the dependency to locate the dependency. For flexibility, rpaths may contain absolute paths, @executable_path or @loader_path. For example, a binary can have an rpath @loader_path/../lib, and a dependency @rpath/library.dylib. After substitution, you have: @loader_path/../lib/library.dylib. With that, go see how @loader_path is handled. If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. > > Which makes it easiest for me, I guess to have @rpath in the id for every > library, and on make install set the exectables' rpath to where I install the > libraries to, and on creating the bundle update the rpaths in the executable > to > the Frameworks folder. The only thing that won't work is running unittests > without installing, but that's not a big problem, for me... > I also find @rpath easiest for me. I make sure all my 3rd party non-system dependencies use @rpath. In my case, these libraries are built once and shared among multiple developers. Using @rpath also allows multiple developers to place these libraries in their own home directories, and CMake's automatic rpath handling helps simplify things. Then when I build my bundles or create packages, I don't need to do any "install_name_tool -change" work. I do set the rpaths on exectuables during install, which is nearly identical to what I do on Linux. I'm curious why the unit tests do not work. Mine work just fine for me. If you have a setting to skip rpaths in the build tree, I guess th
Re: [CMake] still having rpath problems on osx
On Dec 21, 2015 12:26 PM, Boudewijn Rempt wrote: > > I'm still having rpath problems when creating libraries on OSX... And I'm not > sure what's going on here. Here's the output for a single library: > > otool -L ../i/lib/libkritaimage.dylib > ../i/lib/libkritaimage.dylib: > /Users/boud/dev/i/lib/libkritaimage.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritawidgets.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritapsd.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > libboost_system.dylib (compatibility version 0.0.0, current version > 0.0.0) > @rpath/libImath.12.dylib (compatibility version 12.0.0, current version > 12.0.0) > @rpath/libIlmImf.22.dylib (compatibility version 22.0.0, current version > 22.0.0) > @rpath/libIex.12.dylib (compatibility version 12.0.0, current version > 12.0.0) > @rpath/libHalf.12.dylib (compatibility version 12.0.0, current version > 12.0.0) > @rpath/libIlmThread.12.dylib (compatibility version 12.0.0, current > version 12.0.0) > /Users/boud/dev/i/lib/libfftw3.3.dylib (compatibility version 8.0.0, > current version 8.4.0) > @rpath/libgsl.dylib (compatibility version 0.0.0, current version 0.0.0) > /Users/boud/dev/i/lib/libkritaflake.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritaodf.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritaversion.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritastore.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libKF5Archive.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libkritaundo2.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritawidgetutils.15.dylib (compatibility > version 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libKF5ItemViews.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > @rpath/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility > version 5.6.0, current version 5.6.0) > /Users/boud/dev/i/lib/libKF5GuiAddons.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5Completion.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5ConfigGui.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5WidgetsAddons.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libkritaglobal.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility > version 5.6.0, current version 5.6.0) > @rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version > 5.6.0, current version 5.6.0) > /Users/boud/dev/i/lib/libkritapigment.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, > current version 5.6.0) > @rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.6.0, > current version 5.6.0) > /Users/boud/dev/i/lib/libkritaplugin.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libKF5CoreAddons.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5ConfigCore.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, > current version 5.17.0) > @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, > current version 5.6.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.1.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1225.1.1) > > All libraries I link to are built. Some come with a cmake build system, some > with an automake build system, boost with something else altogether... But I > wouldn't have expected the way a library is built to make a difference for > the link lines in the library that links to the other library. You may not expect this, but this is how it works. @rpath is a way for a library to say, "i want to be found using rpaths" > > Obviously, > libboost_system.dylib (compatibility version 0.0.0, current version > 0.0.0) > is wrong -- it's got neither an @rpath, nor a full path. If it is wrong, you need to fix it in boost, or fix it with install_name_tool before linking against it. > > I'm not sure even why some libraries are linked to with @rpath and others > with a > full p
Re: [CMake] fixup bundle vs Qy 5.5.1 and rpaths
It appears you need to add the directory(ies) in the Qt installation containing
the Qt libraries to your DIRS.
set( DIRS
${APP}/Contents/plugins/platforms
${QT_BINARY_DIR}
${QT_LIBRARY_DIR}
)
I think it should have been that way, even with Qt 5.3.
Clint
- On Dec 18, 2015, at 6:12 AM, Gregory Van Vooren
wrote:
> I have a project containing several applications (which are sub projects),
> each
> of which links against some Qt libraries which are built as dylibs, but are
> not
> part of the project. Qt libraries and headers are found using find-package
> which is working perfectly.
> I’m currently trying to switch from Qt 5.3.1 to Qt 5.5.1, but am experiencing
> problems with fixup_bundle on OS X (everything else seems to work fine).
> As far as I’ve gathered Qt has introduced support for rpaths between those two
> version and this seems to be the cause of my problems.
> Building a single application works and said application starts up correctly,
> but building the install target will give me the following output:
> -- fixup_bundle: preparing...
> --
> warning: cannot resolve item 'libQt5Core_debug.5.dylib'
> possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
> -- warning: gp_resolved_file_type non-absolute file 'libQt5Core_debug.5.dylib'
> returning type 'other' -- possibly incorrect
> --
> warning: cannot resolve item 'libQt5Core_debug.5.dylib'
> possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
> warning: target 'libQt5Core_debug.5.dylib' is not absolute...
> warning: target 'libQt5Core_debug.5.dylib' does not exist...
> CMake Error at
> /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:800
> (message):
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool
> failed: 1
> error:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool:
> can't open file: libQt5Core_debug.5.dylib (No such file or directory)
> Call Stack (most recent call first):
> /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:925
> (get_prerequisites)
> /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:555
> (get_prerequisites)
> /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:804
> (get_bundle_keys)
> someApplication/someApplication/cmake_install.cmake:115 (fixup_bundle)
> I’ll try to provide sufficient yet minimal information to pinpoint the root
> cause of the problem.
> In my top CMakeLists.txt I have the following:
> set (
> QT_REQUIRED_PACKAGES
> Core
> Gui
> Widgets
> )
> set( QT_ROOT_PATH "/usr/local/Qt-5.5.1" )
> set( QT_REQUIRED_PACKAGES ${QT_REQUIRED_PACKAGES} MacExtras )
> set(
> QT_PLUGINS_DIR
> "${QT_ROOT_PATH}/plugins"
> )
> set ( CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} "${QT_ROOT_PATH}/bin/" )
> FOREACH(QT_PACKAGE ${QT_REQUIRED_PACKAGES})
> set( QT_PACKAGE_WITH_PREFIX "Qt5${QT_PACKAGE}" )
> set( "${QT_PACKAGE_WITH_PREFIX}_DIR"
> "${QT_ROOT_PATH}/lib/cmake/${QT_PACKAGE_WITH_PREFIX}" )
> find_package( "${QT_PACKAGE_WITH_PREFIX}" REQUIRED )
> include_directories( ${${QT_PACKAGE_WITH_PREFIX}_INCLUDE_DIRS} )
> set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES
> MAP_IMPORTED_CONFIG_DEBUG
> "DEBUG")
> set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES
> MAP_IMPORTED_CONFIG_RELEASE "RELEASE")
> set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES
> MAP_IMPORTED_CONFIG_RELWITHDEBINFO "RELEASE")
> ENDFOREACH(QT_PACKAGE)
> add_definitions( ${QT_DEFINITIONS} )
> set( CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR} )
> set( CMAKE_MACOSX_RPATH “" )
> set_property( GLOBAL PROPERTY USE_FOLDERS ON )
> add_subdirectory( someApplication )
> in the someApplication CMakeLists.txt I have the following:
> set(
> someApplication_Qt_LIBRARIES
> ${Qt5Core_LIBRARIES}
> ${Qt5Widgets_LIBRARIES}
> )
> set_target_properties( someApplication PROPERTIES INSTALL_RPATH
> "${QT_ROOT_PATH}/lib" )
> foreach( OUTPUTCONFIG ${CMAKE_CONFIGURATION_TYPES} )
> install( TARGETS someApplication DESTINATION bin/${OUTPUTCONFIG}
> CONFIGURATIONS
> ${OUTPUTCONFIG} )
> endforeach()
> add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p
> ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/
> )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf
> "${QT_PLUGINS_DIR}/platforms/libqcocoa_debug.dylib"
> ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/
> )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p
> ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Release/plugins/platforms/
> )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf
> "${QT_PLUGINS_DIR}/platforms/libqcocoa.dylib"
> ${CMAKE_INSTALL_PREFIX}/
Re: [CMake] CPack and PackageMaker
If you are interested, attached is some code I started a couple years ago but
never finished, nor did I do much testing.
Perhaps that'll help, or maybe you'll find a better way.
Clint
- On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bie...@dirac.se wrote:
> Dear Attila,
>
> Ok, been struggling getting an installation package to work with the
> pkgbuild/productbild tools, so I think I got the gist of what needs to
> be done, at least to get something going :)
>
> Regards
> /R
>
> Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay:
>> Hi Robert,
>>
>> I'm afraid that the sad situation is that nobody has done this yet, or is
>> working on it at the moment.
>>
>> I'm absolutely sure that if you can help with this by any amount, that will
>> be
>> most welcome by the CMake developers. It will certainly be most welcome by
>> me,
>> as I've been disappointed by the lack of this support as well. (But
>> unfortunately can't spare the time to help out in writing this CPack
>> generator.)
>>
>> Cheers,
>> Attila
>>
>>> On 11 Dec 2015, at 17:44, Robert Bielik wrote:
>>>
>>> Really ? No one ? :)
>>>
>>> So it's ok to go ahead and start create a new one ? ;)
>>>
>>> Rgds,
>>> /R
>>>
>>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik:
>>>> Mac OSX:
>>>>
>>>> Since PackageMaker has been deprecated by Apple, the new tools to use are
>>>> pkgbuild [1] and productbuild [2].
>>>>
>>>> Simple question: Is there any work being done by the CMake community on a
>>>> new OS
>>>> X CPack backend to support the above tools ?
>>>>
>>>> Regards
>>>> /Robert
>>>> [1]
>>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html
>>>> [2]
>>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html
>>>>
>>> --
>>>
>>> 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
commit a49e2b32e9ac1d2d486829c5ee4d8a399530875f
Author: Clinton Stimpson
Date: Sat Nov 2 10:24:53 2013 -0600
add product build generator.
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index a4c982f..79dab75 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -632,6 +632,7 @@ if(APPLE)
CPack/cmCPackDragNDropGenerator.cxx
CPack/cmCPackOSXX11Generator.cxx
CPack/cmCPackPackageMakerGenerator.cxx
+CPack/cmCPackProductBuildGenerator.cxx
)
endif()
diff --git a/Source/CPack/cmCPackGeneratorFactory.cxx b/Source/CPack/cmCPackGeneratorFactory.cxx
index 94ca536..ed1821f 100644
--- a/Source/CPack/cmCPackGeneratorFactory.cxx
+++ b/Source/CPack/cmCPackGeneratorFactory.cxx
@@ -28,6 +28,7 @@
# include "cmCPackBundleGenerator.h"
# include "cmCPackPackageMakerGenerator.h"
# include "cmCPackOSXX11Generator.h"
+# include "cmCPackProductBuildGenerator.h"
#endif
#ifdef __CYGWIN__
@@ -139,6 +140,11 @@ cmCPackGeneratorFactory::cmCPackGeneratorFactory()
this->RegisterGenerator("OSXX11", "Mac OSX X11 bundle",
cm
[CMake] autouic problem with Visual Studio
Hi, I'm trying out the autouic feature in Visual Studio, and I noticed that if I change a .ui file, the corresponding ui_*.h file is not regenerated when I hit the build button. I don't see this problem under Makefiles. For makefiles, it appears a phony target is used and "cmake -E cmake_autogen" is always run each time make is called. For visual studio, the build rule to execute "cmake -E cmake_autogen" has a list of dependencies. This list of dependencies includes all the files listed in a .qrc file, but none of the .ui files. If I right click on the file representing this build rule, and click "compile", it then runs "cmake -E cmake_autogen" and the ui_*.h files are incrementally updated (only those for which corresponding .ui files were changed). This appears to be a bug. The setup is different between the two, and perhaps the build rule under visual studio should list all the dependent .ui files. Is anyone else seeing this behavior? Thanks, Clint -- 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] getting the rpath right on osx
- On Nov 2, 2015, at 2:26 AM, Boudewijn Rempt b...@valdyas.org wrote:
> I checked the manual and the blog post about rpath on osx, but I'm still
> confused, and still not getting it right...
>
> I build and installed Qt 5.6 alpha like this:
>
> ./configure -prefix /Users/boudewijnrempt/kf5/i
>
> Then I made a small test project, consisting of nothing but a main that links
> to
> QtCore.
>
> If I build that with qmake, with this .pro file:
>
> QT += core
> QT -= gui
> TARGET = rpathqmake
> CONFIG += console
> CONFIG -= app_bundle
> TEMPLATE = app
> SOURCES += main.cpp
>
> The r-path is set:
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0,
> current
> version 5.6.0)
>
> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
> (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility
> version 1.0.0, current version 275.0.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1213.0.0)
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0,
> current
> version 5.6.0
Keep in mind, "otool -L" doesn't show rpaths.
@rpath/QtCore.framework/Versions/5/QtCore is not an rpath.
@rpath is a place holder where an rpath can be substituted.
Anytime you see "@rpath" what it means is that the dependent library wants to
be found using rpaths.
Use "otool -l" | grep -A2 LC_RPATH to see the rpaths.
>
> If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and
> without
> all those RPATH related lines,
> they don't seem to make a difference. I'm using cmake 3.3.2.
>
> cmake_minimum_required(VERSION 2.8.12)
> cmake_policy(SET CMP0042 NEW)
> set(CMAKE_MACOSX_RPATH ON)
> SET(CMAKE_SKIP_BUILD_RPATH TRUE)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> set(REQUIRED_QT_VERSION 5.3.0)
> find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
> add_executable(rpathcmake main.cpp)
> target_link_libraries(rpathcmake Qt5::Core)
> install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)
If you remove
set(CMAKE_MACOSX_RPATH ON)
SET(CMAKE_SKIP_BUILD_RPATH TRUE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
then, it would probably be a minimal example.
>
> Only adding something like this makes it work:
>
> set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
> "/Users/boudewijnrempt/kf5/i/lib")
>
> Which I'm pretty sure is something I don't want.
To fix the errors below, you actually to do something like this.
set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
"/Users/boudewijnrempt/kf5/i/lib")
What you probably want is to use a variable instead of an absolute path.
set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
"@loader_path/../lib")
That property along with MACOSX_RPATH, or the global property
CMAKE_MACOSX_RPATH are the 2 first variables you would set.
MACOSX_RPATH property on a target indicates that its install 'ID' contains
@rpath, and it wants to be found using rpaths. INSTALL_RPATH property is a
list of rpaths to help find dependencies which want to be found using rpaths.
>
> Boudewijns-Mac-mini:test boudewijnrempt$ make install
> [100%] Built target rpathcmake
> Install the project...
> -- Install configuration: ""
> -- Up-to-date: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0,
> current
> version 5.6.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
> Boudewijns-Mac-mini:test boudewijnrempt$ ~/kf5/i/bin/rpathcmake
> dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore
> Referenced from: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> Reason: image not found
> Trace/BPT trap: 5
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0,
> current
> version 5.6.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
>
> What should I do?
Set the INSTALL_RPATH target property.
Clint
--
Powered by www.kitware.com
Pleas
Re: [CMake] getting the rpath right on osx
On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote: > Hi, > > On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt wrote: > > On Mon, 2 Nov 2015, Andreas Pakulat wrote: > > > > I think the idea of using @rpath as install name of the Qt libraries is > > > >> geared towards the usecase > >> of shipping Qt within the application bundle of the application. In that > >> case all you need is set > >> the rpath @executable_path/../Frameworks or so in the executable and thus > >> the app-bundle is > >> relocatable. In order to get that with CMake you'll likely need to use > >> the BundleUtilities, though > >> its been so long since I used those I don't know if they can handle this > >> scenario out of the box. > > > > Yes, that's what I'm trying to do -- well, I'm trying to do two > > things. One is setup a build environment where kde apps like desktoptojson > > can run, the other is creating a bundle, preferably using the same > > Qt. I got quite far by manually fixing up the applications built as part > > of kcoreaddons > > That would be fixed in kcoreaddons by extending the linker flags to include > the mentioned -Wl,-rpath,. There's no provisioning for this > inside CMake afaik since its hard for it to guess what the intention is. CMake does automatically handle this. If a library being linked has @rpath for its install ID, then CMake will insert the linker flag. This takes care of the build time rpath. And works for any library in target_link_libraries() where CMake knows its full path. A -L/-l approach does not work, but that is usually done for system libraries, in which case we normally don't care about rpaths. This kind of thing isn't handled automatically at install time, and requires the INSTALL_RPATH property to be set. > My > understanding (not a OSX expert yet here) is also that having the install > name of a framework on OSX be something like @rpath is quite unusual. Thats > usually something that users are 'patching' when they bundle their > application via install_name_tool. And thats what CMake supports doing via > the BundleUtilities module. If install rpaths are set correctly, and all copied 3rd party libraries use @rpath, there is no need for patching with install_name_tool. > > > and then manually patching up the executable inside the > > bundle to have the @executable_path/../Frameworks rpath added. But I'm > > still not sure why with a really simple example things don't work out > > of the box: I guess I had better build Qt with -norpath. > > See above, I think the way the Qt frameworks are setup when using -rpath is > simply not expected/anticipated so far by CMake (or the people maintaining > the qt5 cmake modules inside Qt). It is handled fine by CMake. If not, it would be a bug. > > However I never tried to use BundleUtilities with such a framework, maybe > they do manage to 'fixup' things for that as well. For a Qt4-based project > I'm using INSTALL_QT4_EXECUTABLE which eventually forwards to fixup_bundle > from BundleUtilities, so may be worth a try to avoid the manual steps. > > Even a Qt built with -norpath would require doing some 'manual' things to > get a all-in-one app bundle for the application (or use of > BundleUtilities), to copy things around and adjust the install and link > names in all the frameworks and executables to be related and thus make the > application relocatable. Yes, a Qt built with -norpath will require extra patching steps with install_name_tool. Clint -- 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] Use CMAKE_MACOSX_RPATH to link a library outside build tree
On Sunday, August 23, 2015 04:46:17 AM Oleg Zhylin via CMake wrote: > Hi All, > I still need help with 0015708: Use CMAKE_MACOSX_RPATH to link a library > outside build tree - MantisBT. Could you please suggest are there any CMake > mechanisms to ensure a library outside build tree on mac is linked with > either @rpath and using hard-coded path on build machine? Either option > would actually help. > | | > | | | | | | > | 0015708: Use CMAKE_MACOSX_RPATH to link a library outside build tree - > | MantisBTThis issue is Mac OS X specific. I would like to link a library > | lib_xxx that sits outside my build tree at some arbitrary location. It > | will be at the same location in all systems. | > | > | View on www.cmake.org | Preview by Yahoo | > | > | | > > WBR ovz There is no CMake mechanism to control references when linking with external libraries. If you still want to do this, you'll need to edit the references in your binaries after linking. You'll be much better off if you modify the external libraries. For @rpath, use a command like this: or For absolute path If those external libraries have additional dependencies using @executable_path, you may also need to use "install_name_tool -change ..." Clint -- 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 removes rpath from Linux binaries. How to stop
- Original Message - > I am trying to create a standalone build of our application on Linux. We are > currently building on a mix of Mint 17 and Ubuntu 14.04. I have been doing a > lot of reading about rpath, runpath and chrpath. The only way it would seem > to get this done is to adjust the rpath via the "chrpath" tool. The issue is > that during packaging, cmake is removing the rpath from the binaries which > kills the process of using chrpath. I have looked at the various *_RPATH* > cmake variables but none of the combinations seem to work correctly. CMake > always strips the rpath from the binaries. This is with a Qt5 application > which compiles against the Qt 5.4.1 version which is installed from the > Qt.io website. Have you tried only setting the INSTALL_RPATH property on the targets? Or setting the CMAKE_INSTALL_RPATH in your top level CMakeLists.txt file. For example: if (CMAKE_SYSTEM_NAME MATCHES "Linux" ) set (CMAKE_ INSTALL _RPATH "\$ORIGIN" ) endif () That alone should be enough to give you rpaths in the install tree. Clint -- 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] Are CMAKE_CXX_FLAGS supposed to go on the link line?
FYI,
I also came across this discrepancy recently, and logged a bug for it.
http://www.cmake.org/Bug/view.php?id=15427
With the example provided in the bug report, I am seeing link errors under
Xcode which I do not see under Makefiles.
Clint
On Monday, March 02, 2015 07:33:38 PM Roman Bolshakov wrote:
> Apparently, command line to link executable is quite different from a
> shared library (Modules/CMakeCXXInformation.cmake):
>
> if(NOT CMAKE_CXX_LINK_EXECUTABLE)
> set(CMAKE_CXX_LINK_EXECUTABLE
> "
> -o ")
> endif()
>
>
> set(CMAKE_CXX_CREATE_SHARED_LIBRARY
> "
>
>
> -o ")
>
> CMAKE_CXX_FLAGS/CMAKE_C_FLAGS which are filled into
> don't go into a linker command for
> executable.
>
> 2015-01-22 19:11 GMT+03:00 Paul Smith :
> > I didn't get a response to the question below. I've since reproduced
> > this with a simple test case; maybe someone can let me know why this
> > difference appears and how I should handle it? I'm using cmake 3.1.0:
> >
> > Sample CMakeLists.txt:
> > $ cat >CMakeLists.txt < > cmake_minimum_required(VERSION 3.1.0)
> > project(FlagTest)
> > set(CMAKE_CXX_FLAGS -pthread)
> > add_executable(foo foo.cpp)
> > EOF
> >
> > $ echo 'int main(int argc, char**argv) { return 0; }' > foo.cpp
> >
> > On MacOSX with Xcode installed, I see the following behavior:
> > $ cmake -G Xcode . && cmake --build . 2>&1 | tee xc.out
> >
> > In the output I see that the "-pthread" flag DOES appear on the compile
> >
> > line for "foo.o", but DOES NOT appear in the link line for "foo":
> > $ grep pthread xc.out
> > /.../clang -x c++ ... -pthread ... -c /.../foo.cpp -o /.../foo.o
> >
> > This is correct for clang, which does not want -pthread on the link line
> > (unlike GCC, which wants it in both places). Now, I clean that up and
> >
> > try with the Makefile generator, and I see the following behavior:
> > $ cmake -G 'Unix Makefiles' . && cmake --build . -- VERBOSE=1 2>&1 | tee
> > mk.out clang: warning: argument unused during compilation: '-pthread'
> >
> > Now in this case we can see that the -pthread flag was added to BOTH the
> >
> > compile and the link line:
> > $ grep pthread mk.out
> > /usr/bin/c++ -pthread -o .../foo.cpp.o -c .../foo.cpp
> > /usr/bin/c++ -pthread .../foo.cpp.o -o foo
> > clang: warning: argument unused during compilation: '-pthread'
> >
> > This warning is totally bogus: it really means "unused during LINKING",
> > but anyway: I'm not sure what to do to get rid of this warning: I need
> > to support both Xcode and Makefiles on MacOSX (and Makefiles on Linux as
> > well as both GCC and Clang).
> >
> > Is the intent that CMAKE_CXX_FLAGS only ever appear on the compile line?
> > Or should it appear on both the compile and link lines? Is there an
> > equivalent flag to CMAKE_EXE_LINKER_FLAGS that always applies only to
> > compile lines, in all generators? Do we just have to continue to
> > bastardize add_definitions() for this, maybe?
> >
> > On Thu, 2015-01-08 at 18:52 -0500, Paul Smith wrote:
> >> If I'm on OSX, then when I set CMAKE_CXX_FLAGS and do not set
> >> CMAKE_EXE_LINKER_FLAGS, for example, and I use the Xcode generator,
> >> then
> >>
> >> I see:
> >> * CMAKE_CXX_FLAGS show up on the compilation line
> >> * CMAKE_CXX_FLAGS do NOT show up in the linker line
> >>
> >> On the other hand if I'm on OSX and I use the Unix Makefiles
> >> generator,
> >>
> >> then I see:
> >> * CMAKE_CXX_FLAGS show up on the compilation line
> >> * CMAKE_CXX_FLAGS ALSO show up in the linker line
> >>
> >> I assume the Xcode output is correct and the makefile output (with
> >> CMAKE_CXX_FLAGS in both) is not correct... but there's nothing I can
> >> find in the docs that says this explicitly.
> >>
> >> I've printed the contents of the CMAKE_CXX_FLAGS and
> >> CMAKE_EXE_LINKER_FLAGS at the end of my CMakeLists.txt and they're
> >> just
> >> what I expect. It's just that the link line has extra flags, when
> >> invoked from make.
> >
> > --
> >
> > 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.o
Re: [CMake] CPack: .desktop files with tar.gz maker?
- Original Message - > On 11/7/14, Clinton Stimpson wrote: > > On Friday, November 07, 2014 03:50:32 PM Eric Wing wrote: > >> I have a build and packaging system where I can distribute (mostly) > >> standalone apps for Linux desktop. I am using the default CPack > >> installer which creates .tar.gz, .Z, and .sh files. > >> > >> I like this opposed to the .deb/.rpm package systems because users > >> don't need root access to install/use my stuff (and can place > >> anywhere), and I only need a single package for all Linux desktops. > >> > >> But it's pretty plain-Jane and it would be nice to provide an icon or > >> something. So I was wondering if anybody had > >> suggestions/advice/strategies on supporting .desktop files. As far as > >> I can tell, I need paths to the icon and the executable, which is > >> completely variable based on where the user puts it. And I'm not sure > >> where this file is supposed to be written to. (Remember that I don't > >> use root access.) > >> > >> Thanks, > >> Eric > > > > Perhaps you can do this: > > > > Include the .desktop file in your installation. > > > > To add, your installer can call > > xdg-desktop-menu install /share/applications/MyApp.desktop > > > > To remove, your installer can call > > xdg-desktop-menu uninstall /share/applications/MyApp.desktop > > > > If xdg-desktop-menu is called as root, it'll copy the .desktop file to the > > system location. If it is called as a non-root user, it'll copy the file > > to > > > > the user specific desktop area. xdg-desktop-menu also takes care of > > refreshing > > the icons in the launcher. > > > > During uninstall, it'll remove the copy. > > > > By the way, we do .rpm and .deb, but also give instructions for users to > > extract the files if they want their own installation directory. > > > > The above .desktop support can be put in a script and added to the postinst > > > > and prerm scripts for rpm and deb. > > > > This makes things more automatic for the majority of our users (basically > > download-click-and-run). > > > > Clint > > > > > > Thanks for the information. Based on that, I wrote a script that is > bundled with the contents and when run, will generate the correct > .desktop file with the correct absolute paths needed and invoke > xdg-desktop-menu install. > > I noticed that the CPack tarball generator also generates a > self-extracting .sh ball. Is there anyway to hook into that to add a > postinst like stage so I can invoke my script? > You can copy CMake/Modules/CPack.STGZ_Header.sh.in, make your modifications, then set CPACK_STGZ_HEADER_FILE to point to it. Clint -- 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] CPack: .desktop files with tar.gz maker?
On Friday, November 07, 2014 03:50:32 PM Eric Wing wrote: > I have a build and packaging system where I can distribute (mostly) > standalone apps for Linux desktop. I am using the default CPack > installer which creates .tar.gz, .Z, and .sh files. > > I like this opposed to the .deb/.rpm package systems because users > don't need root access to install/use my stuff (and can place > anywhere), and I only need a single package for all Linux desktops. > > But it's pretty plain-Jane and it would be nice to provide an icon or > something. So I was wondering if anybody had > suggestions/advice/strategies on supporting .desktop files. As far as > I can tell, I need paths to the icon and the executable, which is > completely variable based on where the user puts it. And I'm not sure > where this file is supposed to be written to. (Remember that I don't > use root access.) > > Thanks, > Eric Perhaps you can do this: Include the .desktop file in your installation. To add, your installer can call xdg-desktop-menu install /share/applications/MyApp.desktop To remove, your installer can call xdg-desktop-menu uninstall /share/applications/MyApp.desktop If xdg-desktop-menu is called as root, it'll copy the .desktop file to the system location. If it is called as a non-root user, it'll copy the file to the user specific desktop area. xdg-desktop-menu also takes care of refreshing the icons in the launcher. During uninstall, it'll remove the copy. By the way, we do .rpm and .deb, but also give instructions for users to extract the files if they want their own installation directory. The above .desktop support can be put in a script and added to the postinst and prerm scripts for rpm and deb. This makes things more automatic for the majority of our users (basically download-click-and-run). Clint -- 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] Installation corrupts library on OS X
On Tuesday, October 21, 2014 06:52:58 PM Filipe Maia wrote:
> CMake's FindCUDA.cmake module adds the rpath when run on Mac OSX
> (from FindCUDA.cmake):
>
> if(APPLE)
> # We need to add the path to cudart to the linker using rpath, since the
> # library name for the cuda libraries is prepended with @rpath.
> if(CUDA_BUILD_EMULATION AND CUDA_CUDARTEMU_LIBRARY)
> get_filename_component(_cuda_path_to_cudart "${CUDA_CUDARTEMU_LIBRARY}"
> PATH)
> else()
> get_filename_component(_cuda_path_to_cudart "${CUDA_CUDART_LIBRARY}"
> PATH)
> endif()
> if(_cuda_path_to_cudart)
> list(APPEND CUDA_LIBRARIES -Wl,-rpath "-Wl,${_cuda_path_to_cudart}")
> endif()
> endif()
>
> This causes this problem for anything built with CUDA support
> (e.g. CUDA_ADD_EXECUTABLE), by having one rpath from the CUDA module and
> another one from cmake trying its automagic.
> The rpath should probably be removed from the module.
Oh! It comes from Modules/FindCUDA.cmake. That does need fixed.
Does the attached patch fix your problem?
Clint
> On Tue, Oct 14, 2014 at 9:56 PM, Clinton Stimpson
>
> wrote:
> > On Tuesday, October 14, 2014 12:10:36 PM Peter Eastman wrote:
> > > Hi Clint,
> > >
> > > In my case, it wasn't anything like that. I was only specifying
> > > /usr/local/cuda/lib once. More specifically, my CMakeLists.txt
> > > specified
> > >
> > > TARGET_LINK_LIBRARIES(${SHARED_TARGET} ${CUDA_LIBRARIES})
> > >
> > > where CUDA_LIBRARIES is
> > >
> > > /usr/local/cuda/lib/libcudart.dylib-Wl,-rpath-Wl,/usr/local/cuda/lib
> >
> > Since CMake 2.8.12, CMake will automatically figure out the
> > -Wl,-rpath-Wl,/usr/local/cuda/lib part for
> > /usr/local/cuda/lib/libcudart.dylib.
> >
> > So, the duplicate comes from CMake adding it once, and you adding it once.
> >
> > You should be able to remove any -Wl,-rpath flags that you add manually
> > with
> > CMake 2.8.12 and newer, and let CMake take care of that for you.
> >
> > > This library also linked against another of my libraries, that also
> >
> > happened
> >
> > > to link against CUDA. So that's why it was getting referenced twice:
> > once
> >
> > > directly, and once indirectly via a second library.
> > >
> > > In any case, it's not clear to me why CMake is calling
> > > "install_name_tool
> > > -delete_rpath". Everything works fine without doing that. And when you
> >
> > do
> >
> > > it, that breaks things.
> >
> > CMake calls "install_name_tool -delete_rpath" at install time to remove
> > the
> > build rpaths and add install rpaths as specified by the INSTALL_RPATH
> > target
> > property.
> >
> > For more details and examples:
> > http://www.kitware.com/blog/home/post/510
> > http://www.cmake.org/Wiki/CMake_RPATH_handling
> >
> > Clint
> >
> > > Peter
> > >
> > > On Oct 14, 2014, at 11:06 AM, Clinton Stimpson
> >
> > wrote:
> > > > Here's a simple way to reproduce from the command line:
> > > >
> > > > echo "void foo() {}" > lib.c
> > > > gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib
> >
> > -Wl,-rpath,/usr/lib
> >
> > > > lib.c install_name_tool -delete_rpath /usr/lib libtest.dylib
> > > > otool -L libtest.dylib
> > > >
> > > > # gives me the error: "load command 13 size zero (can't advance to
> >
> > other
> >
> > > > load commands)"
> > > >
> > > > At install time, CMake will call "install_name_tool -delete_rpath ...
> >
> > " as
> >
> > > > needed.
> > > >
> > > > I can't get into Apple's bug tracker. I don't know why. When I try
> > > > to
> > > > log
> > > > in, it comes back with a generic error and it asks me to email them
> >
> > with
> >
> > > > details about the error.
> > > >
> > > > When I do the same on Linux, the GNU linker will consolidate the
> >
> > duplicate
> >
> > > > paths.
> > > >
> > > > Thanks!
> > > >
> > > > Clint
> >
> > --
> > Clinton Stimpson
> > Elemental Technologies, Inc
> > Computational Simulation Software, LLC
> > www.csimsoft.com
> > --
>
[CMake] cache variables from compiler checks
I noticed something odd... If I delete the cache variable CMAKE_STRIP, then re-run cmake, it doesn't come back. If I delete the build/CMakeFiles directory, re-run cmake, it'll come back. Is that intentional? I have a dashboard build where I was re-configuring with a different initial CMakeCache.txt file, and some of the variables don't come back. Looks like I'll also need to remove the CMakeFiles directory while I write the CMakeLists.txt file. Clint -- 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] Installation corrupts library on OS X
On Tuesday, October 14, 2014 12:10:36 PM Peter Eastman wrote:
> Hi Clint,
>
> In my case, it wasn't anything like that. I was only specifying
> /usr/local/cuda/lib once. More specifically, my CMakeLists.txt specified
>
> TARGET_LINK_LIBRARIES(${SHARED_TARGET} ${CUDA_LIBRARIES})
>
> where CUDA_LIBRARIES is
>
> /usr/local/cuda/lib/libcudart.dylib-Wl,-rpath-Wl,/usr/local/cuda/lib
Since CMake 2.8.12, CMake will automatically figure out the
-Wl,-rpath-Wl,/usr/local/cuda/lib part for
/usr/local/cuda/lib/libcudart.dylib.
So, the duplicate comes from CMake adding it once, and you adding it once.
You should be able to remove any -Wl,-rpath flags that you add manually with
CMake 2.8.12 and newer, and let CMake take care of that for you.
>
> This library also linked against another of my libraries, that also happened
> to link against CUDA. So that's why it was getting referenced twice: once
> directly, and once indirectly via a second library.
>
> In any case, it's not clear to me why CMake is calling "install_name_tool
> -delete_rpath". Everything works fine without doing that. And when you do
> it, that breaks things.
CMake calls "install_name_tool -delete_rpath" at install time to remove the
build rpaths and add install rpaths as specified by the INSTALL_RPATH target
property.
For more details and examples:
http://www.kitware.com/blog/home/post/510
http://www.cmake.org/Wiki/CMake_RPATH_handling
Clint
>
> Peter
>
> On Oct 14, 2014, at 11:06 AM, Clinton Stimpson wrote:
> > Here's a simple way to reproduce from the command line:
> >
> > echo "void foo() {}" > lib.c
> > gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib -Wl,-rpath,/usr/lib
> > lib.c install_name_tool -delete_rpath /usr/lib libtest.dylib
> > otool -L libtest.dylib
> >
> > # gives me the error: "load command 13 size zero (can't advance to other
> >
> > load commands)"
> >
> > At install time, CMake will call "install_name_tool -delete_rpath ... " as
> > needed.
> >
> > I can't get into Apple's bug tracker. I don't know why. When I try to
> > log
> > in, it comes back with a generic error and it asks me to email them with
> > details about the error.
> >
> > When I do the same on Linux, the GNU linker will consolidate the duplicate
> > paths.
> >
> > Thanks!
> >
> > Clint
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.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] Installation corrupts library on OS X
On Tuesday, October 14, 2014 10:19:41 AM Peter Eastman wrote:
> Hi Clint,
>
> You're absolutely right:
>
> $ otool -l libOpenMMAmoebaCUDA.dylib | grep -A2 LC_RPATH
> cmd LC_RPATH
> cmdsize 32
> path /usr/local/cuda/lib (offset 12)
> --
> cmd LC_RPATH
> cmdsize 32
> path /usr/local/cuda/lib (offset 12)
>
> I'll try to figure out where the duplicate is coming from and see if that
> fixes it.
>
> I'd be glad to report this to Apple, but I can't figure out how to reproduce
> the problem without using CMake. I tried using install_name_tool to
> directly change all the paths myself, and that worked fine. It didn't
> produce the problem. Is CMake doing something different from just a series
> of calls to "install_name_tool -change" and "install_name_tool -id"?
>
> Peter
Here's a simple way to reproduce from the command line:
echo "void foo() {}" > lib.c
gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib -Wl,-rpath,/usr/lib lib.c
install_name_tool -delete_rpath /usr/lib libtest.dylib
otool -L libtest.dylib
# gives me the error: "load command 13 size zero (can't advance to other
load commands)"
At install time, CMake will call "install_name_tool -delete_rpath ... " as
needed.
I can't get into Apple's bug tracker. I don't know why. When I try to log
in, it comes back with a generic error and it asks me to email them with
details about the error.
When I do the same on Linux, the GNU linker will consolidate the duplicate
paths.
Thanks!
Clint
>
> On Oct 13, 2014, at 7:33 PM, clin...@elemtech.com wrote:
> > Yeah, I think you have duplicate LC_RPATH load commands. In that case,
> > your binaries can be corrupted by install_name_tool during "make
> > install." To check if that is your case, you can run this on the binary
> > before installation to see if you have duplicates. otool -l app | grep
> > -A2 LC_RPATH
> >
> > If the duplicates come from your own linker flags such as,
> > -Wl,-rpath,/some/path, you may need to remove those. Otherwise, it would
> > help if you can provide a minimal test case to reproduce the problem.
> >
> > It would also help if someone could report this corruption by
> > install_name_tool bug to Apple. You are the second to come to this
> > mailing list about this bug.
> >
> > Clint
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.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] Installation corrupts library on OS X
- Original Message - > Hi, > I'm using CMake 3.0.2 on OS X 10.9.4. When I do a "make install", it's > somehow corrupting some of my libraries at install time. > Here is what otool reports for the library in my build directory - that is, > the state of the library prior to installation: > $ otool -L libOpenMMAmoebaCUDA.dylib > libOpenMMAmoebaCUDA.dylib: > /Users/peastman/workspace/openmm/bin-release/libOpenMMAmoebaCUDA.dylib > (compatibility version 0.0.0, current version 0.0.0) > @rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current > version 6.0.37) > /Users/peastman/workspace/openmm/bin-release/libOpenMM.dylib (compatibility > version 0.0.0, current version 0.0.0) > @rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version > 6.0.37) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1197.1.1) > /Users/peastman/workspace/openmm/bin-release/libOpenMMCUDA.dylib > (compatibility version 0.0.0, current version 0.0.0) > /Users/peastman/workspace/openmm/bin-release/libOpenMMAmoeba.dylib > (compatibility version 0.0.0, current version 0.0.0) > /usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current > version 6.0.37) > @rpath/libcufft.6.0.dylib (compatibility version 0.0.0, current version > 6.0.37) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.0.0) > No problems. Everything looks ok. Now here is what it reports for the same > library in the install directory - the is, the state of the library after > installation: > $ otool -L /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib > /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib: > @rpath/libOpenMMAmoebaCUDA.dylib (compatibility version 0.0.0, current > version 0.0.0) > @rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current > version 6.0.37) > @rpath/libOpenMM.dylib (compatibility version 0.0.0, current version 0.0.0) > @rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version > 6.0.37) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1197.1.1) > @rpath/libOpenMMCUDA.dylib (compatibility version 0.0.0, current version > 0.0.0) > @rpath/libOpenMMAmoeba.dylib (compatibility version 0.0.0, current version > 0.0.0) > /usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current > version 6.0.37) > @rpath/libcufft.6.0.dylib (compatibility version 0.0.0, current version > 6.0.37) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.0.0) > load command 22 size zero (can't advance to other load commands) > As expected, the absolute paths have been replaced by relative paths. But it > also now reports an error message at the end about "load command 22 size > zero". This error does not prevent the library from actually being loaded. > It seems to work fine as far as that is concerned. However, if I try to use > install_name_tool to make any further changes to the paths in the library it > fails with an error message: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: > for architecture i386 object: > /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib malformed object > (load command 22 cmdsize is zero) > Any idea what's going on? Yeah, I think you have duplicate LC_RPATH load commands. In that case, your binaries can be corrupted by install_name_tool during "make install." To check if that is your case, you can run this on the binary before installation to see if you have duplicates. otool -l app | grep -A2 LC_RPATH If the duplicates come from your own linker flags such as, -Wl,-rpath,/some/path, you may need to remove those. Otherwise, it would help if you can provide a minimal test case to reproduce the problem. It would also help if someone could report this corruption by install_name_tool bug to Apple. You are the second to come to this mailing list about this bug. Clint -- 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] VERSION and SOVERSION target properties on OS X
On Friday, October 10, 2014 12:43:53 PM Steven Velez wrote: > Forgive me if this question has been answered before but with CMAKE 2.8.12 > (I believe) xcode builds on OS X started generating shared libraries > decorated with the "VERSION" target property and symlinked by a bare dylib > name and one decorated with the SOVERSION. > > I understand this is common practice on many unixen, but it is complicating > our deployment and update logic (not cpack, sorry to say). > > Our application is fairly self-contained, so we would like to continue > generating only those bare-named dylibs, but we need to keep the SOVERSION > set to that the embedded "compatibility version" remains how we want it. > > I have not found a combination of values to these properties that does what > I would like, so I was wondering if there was a way to get the old > behavior perhaps with a policy or something? > > If there isn't a way to do it now, would there be an acceptable way to > specify this behavior that would be accepted as a patch? > > Thanks, > Steven That change was made to make the Xcode and Makefile generators consistent. To get what you want now (with both the older and newer CMake versions), you can remove the SOVERSION property and set the LINK_FLAGS property to pass - compatibilty_version to the linker. Clint -- 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] CPack DragNDrop, adding an additional file to DMG
On Thursday, September 25, 2014 10:19:23 AM jmerkow wrote: > Yes. > > Im actually using the Bundle generator. We don't use bundle when compiling. > We only use bundles to launch for the binaries. DESTINATION "." points to > Contents/Resources/ in this case. > > -Jameson > Sorry, the Bundle generator doesn't let you do that. This is one of the reasons we have the DragNDrop generator, so you should use that instead. To do that, you'll also need to change your application to be a bundle in the build directory. You can also use variables for the DESTINATION parameter in your install() commands. Clint -- 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] CPack DragNDrop, adding an additional file to DMG
On Thursday, September 25, 2014 08:36:18 AM jmerkow wrote: > Using CPack is it possible to add an additional file to the DMG? Many DMGs > accompany their bundles with readme's or other files. I haven't found > anything in the documentation to accomplish this. > > -Jameson Have you tried this? install(FILES readme.txt DESTINATION ".") -Clint -- 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_CFG_INTDIR
- Original Message -
> On 15/09/14 12:01, Daniele E. Domenichelli wrote:
> > Is there an alternative variable for CMAKE_CFG_INTDIR that can be used
> > in configure time, instead of build time?
> >
> > If there is not, is it safe to assume that the name of the directory is
> > equal to the name of the current configuration?
>
>
> Bump?
>
> What I would like to do is to be able to change
> CMAKE_RUNTIME_OUTPUT_DIRECTORY (and similar variables) with something
> that contains the current configuration directory, i.e.
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY .../${CMAKE_CFG_INTDIR}/...)
>
> but unfortunately CMAKE_CFG_INTDIR causes an error when targets are
> installed.
As expected, that will not work. CMAKE_CFG_INTDIR can give the build tool a
variable, which is expanded by the build tool, and you've effectively added
another configuration directory level.
You could end up with a directory such as
/path/to/Debug/Debug/
>
> I was able to have something that works as I expect by doing this:
>
> foreach(config ${CMAKE_CONFIGURATION_TYPES})
> string(TOUPPER ${config} CONFIG)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONFIG} .../${config}/...)
> endforeach()
>
> But I was wondering if it is safe to assume that the current directory
> is always "${config}" or if it might be different.
>
That should work just fine. CMAKE_CONFIGURATION_TYPES gives you a list of all
possible configuration that can be chosen at build time.
Clint
--
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] Setting additional Plist values for OS X Bundle
On Monday, August 25, 2014 01:10:27 PM Michael Jackson wrote:
> Are there are newer facilities in CMake 3.x that would allow me to add
> additional Plist values to the standard Mac OS X bundle plist that gets
> created?
>
> I use the following code currently:
>
> set_target_properties(${TARGET_NAME} PROPERTIES
> MACOSX_BUNDLE_INFO_STRING "${PROJECT_NAME}${DBG_EXTENSION} Version
> ${VERSION_STRING}, Copyright 2014 BlueQuartz Software."
> MACOSX_BUNDLE_ICON_FILE ${ICON_FILE_NAME}
> MACOSX_BUNDLE_GUI_IDENTIFIER "${PROJECT_NAME}${DBG_EXTENSION}"
> MACOSX_BUNDLE_LONG_VERSION_STRING "${PROJECT_NAME}${DBG_EXTENSION}
> Version ${VERSION_STRING}" MACOSX_BUNDLE_BUNDLE_NAME
> ${PROJECT_NAME}${DBG_EXTENSION}
> MACOSX_BUNDLE_SHORT_VERSION_STRING ${VERSION_STRING}
> MACOSX_BUNDLE_BUNDLE_VERSION ${VERSION_STRING}
> MACOSX_BUNDLE_COPYRIGHT "Copyright 2014, BlueQuartz Software. All
> Rights Reserved." )
>
>
> But I need to add the following to my plist:
>
> NSHighResolutionCapable
> True
>
>
> Thanks for any help
> --
> Mike Jackson www.bluequartz.net
Even with CMake 2.x, you can make your own .plist.in copied from
CMake/Modules/MacOSXBundleInfo.plist.in, then add your part in there.
NSHighResolutionCapable
True
Then add one more line to your set of target properties:
MACOSX_BUNDLE_INFO_PLIST
"${CMAKE_CURRENT_SOURCE_DIR}/MacOSXBundleInfo.plist.in"
- Clint
--
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 3.0 and Visual Studio 2013 peculiarities
On Tuesday, August 05, 2014 11:30:57 AM Nagy-Egri Máté Ferenc wrote: > Hi! > > > > > I have been using CMake for quite some time now, but there are a few things > I don’t understand or I just don’t know how to accomplish. > > 1) Some time ago I posted about Unicode paths inside generated project files > do not work properly. The issue has been fixed. Though this issue is only a > cosmetic one, when I genetate anything with CMake under such a path I see > > -- Build files have been written to: > C:/Users/MßtÚFerenc/OneDrive/Develop/Active/GridRipper/VS2013 > > in the command line, where the actual path should contain “MátéFerenc”. I > don’t know if the displayed string internally is stored this way, or the > encoding gets messed at the very last moment when printed to the console. > Inspecting which is the case might uncover some bugs. Its messed up when printed to the console. CMake is using the ANSI code page, but your console is using the OEM code page. If you look at the two tables for your ANSI and OEM code pages, you'll see that á on the ANSI code page is the same as ß on the OEM code page. So, when CMake prints the á character, the console displays the ß character. There is a chcp command you can use to change your console code page to your ANSI code page to fix the display. - Clint -- 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] Mac @loader_path for @rpath questions
- Original Message -
> I have a bunch of libraries and frameworks that properly use @rpath.
> Now I am trying to build an application that uses those library and
> frameworks via CMake.
>
> From this blog:
> http://www.kitware.com/blog/home/post/510
> I see I am supposed to do:
> set(CMAKE_MACOSX_RPATH 1)
The above should be set before declaring an @rpath target, which is one that
has an install name with @rpath.
> set_target_properties(bar PROPERTIES INSTALL_RPATH "@loader_path/../lib")
The above should be set for any targets that use an @rpath target. So those 2
lines don't necessarily go together.
>
> So now, I am trying to improve my user experience with this. So a
> couple of questions:
>
> 1) I noticed it only applies the @loader_path stuff when I "install"
> with CMake. I would like this applied during build because "install"
> is very unnatural on Mac where drag-and-drop is king. I was expecting
> set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) to help, but it doesn't seem
> to have an affect.
Setting CMAKE_BUILD_WITH_INSTALL_RPATH should have an effect, if set before any
targets that link with the @rpath libraries.
Can you provide an example of what you are doing, so we can find out why its
not working for you?
I understand drag-and-drop, but it doesn't work for my situations. I have
several 3rd party libraries that are not in system locations, and are not part
of the build tree, so setting CMAKE_BUILD_WITH_INSTALL_RPATH breaks my builds.
Install time is where I get a complete .app bundle.
>
>
> 2) I have both .dylibs and .frameworks. It is customary to bundle
> frameworks in .app/Contents/Frameworks/ and somewhat customary to
> bundle .dylibs in ./app/Contents/lib
> This means I need to specify multiple "Runtime Search Path"
> (LD_RUNPATH_SEARCH_PATHS) which Apple/Xcode fully allows, i.e. I need
> both:
> set_target_properties(bar PROPERTIES INSTALL_RPATH
> "@loader_path/../Frameworks")
> set_target_properties(bar PROPERTIES INSTALL_RPATH "@loader_path/../lib")
> How do I declare this for CMake?
>
With a list.
set_target_properties(bar PROPERTIES INSTALL_RPATH
"@loader_path/../Frameworks;@loader_path/../lib")
>
> 3) What is the common way people copy their frameworks into their .app
> bundle now-a-days?
I do it at install time by setting the install destination to be inside the
.app bundle.
> I was hoping I could get away with:
>
> SET_SOURCE_FILES_PROPERTIES(
> ${MY_LIBRARIES}
> PROPERTIES
> MACOSX_PACKAGE_LOCATION Frameworks
> )
> But CMake just creates an empty directory like:
> .app/Contents/Frameworks/ALmixer.framework
> with none of the stuff inside the framework. (It doesn't recursively
> copy the directory.)
I've never used MACOSX_PACKAGE_LOCATION, so I'm not sure how it works.
Clint
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] undesirable Bdynamic/Bstatic link flags
I have a machine I'm trying to compile some code on, and CMake is apparently being smart and is inserting -Wl,-Bdynamic around some of the libraries from the CMAKE_CXX_IMPLICIT_LINK_LIBRARIES variable. Is there a way to stop that? Or is there a reason why it is doing that? Thanks, Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install name for fortran dylibs on mac
I've attached a sample project which includes 2 external projects, where the executable links with the library from its build tree. After it is built, you can run it from the build tree ./app-prefix/src/app-build/app Clint - Original Message - > When using @rpath, the proper way to the executable to find it at runtime is > for the executable to have an rpath with a directory that contains the > dylib. > When compiling the executable, the linker flag "-rpath /path/to/dylib" should > be given. This should be automatic with CMake when building the executable, > and if it isn't doing that for you, please give us an example. > To verify, the executable has the rpath, you can run "otool -l | > grep LC_RPATH -A2" > Clint > - Original Message - > > So I noticed the CMAKE_MACOSX_RPATH variable, and tried setting it, which > > does result in the install name of the dylib being set to > > @rpath/dylibname.so BUT when I link it in an executable tool -L just shows > > the dylib as @rpath/dylibname.so and the linker fails to find it at run > > time. What is the proper way to get CMake to build the executable linking > > against the dylib and be able to run it in the build tree and install tree? > > > Izaak Beekman > > > === > > > (301)244-9367 > > > UMD-CP Visiting Graduate Student > > > Aerospace Engineering > > > ibeek...@umiacs.umd.edu > > > ibeek...@umd.edu > > > On Sat, May 3, 2014 at 10:54 AM, Dan Kegel < d...@kegel.com > wrote: > > > > On Sat, May 3, 2014 at 7:17 AM, < clin...@elemtech.com > wrote: > > > > > > > Use at least CMake 2.8.12 and in your library project add this: > > > > > > > set(CMAKE_MACOSX_RPATH 1) > > > > > > > ... > > > > > > > For more details: > > > > > > > http://www.kitware.com/blog/home/post/510 > > > > > > What he said. See also past discussion at > > > > > > http://web.archiveorange.com/archive/v/5y7PkspCBZwiWhvodZSP > > > > > > I put together some tiny demos showing various ways to do it, with > > > > > > walkthroughs, at > > > > > > http://kegel.com/macosx/rpath/ > > > > -- > 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://www.cmake.org/mailman/listinfo/cmake test-rpath.tar.gz Description: application/compressed-tar -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install name for fortran dylibs on mac
When using @rpath, the proper way to the executable to find it at runtime is for the executable to have an rpath with a directory that contains the dylib. When compiling the executable, the linker flag "-rpath /path/to/dylib" should be given. This should be automatic with CMake when building the executable, and if it isn't doing that for you, please give us an example. To verify, the executable has the rpath, you can run "otool -l | grep LC_RPATH -A2" Clint - Original Message - > So I noticed the CMAKE_MACOSX_RPATH variable, and tried setting it, which > does result in the install name of the dylib being set to > @rpath/dylibname.so BUT when I link it in an executable tool -L just shows > the dylib as @rpath/dylibname.so and the linker fails to find it at run > time. What is the proper way to get CMake to build the executable linking > against the dylib and be able to run it in the build tree and install tree? > Izaak Beekman > === > (301)244-9367 > UMD-CP Visiting Graduate Student > Aerospace Engineering > ibeek...@umiacs.umd.edu > ibeek...@umd.edu > On Sat, May 3, 2014 at 10:54 AM, Dan Kegel < d...@kegel.com > wrote: > > On Sat, May 3, 2014 at 7:17 AM, < clin...@elemtech.com > wrote: > > > > Use at least CMake 2.8.12 and in your library project add this: > > > > set(CMAKE_MACOSX_RPATH 1) > > > > ... > > > > For more details: > > > > http://www.kitware.com/blog/home/post/510 > > > What he said. See also past discussion at > > > http://web.archiveorange.com/archive/v/5y7PkspCBZwiWhvodZSP > > > I put together some tiny demos showing various ways to do it, with > > > walkthroughs, at > > > http://kegel.com/macosx/rpath/ > -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install name for fortran dylibs on mac
- Original Message - > Hi, > After much head scratching and googling, I found a way to get the dynamic > library built in a project of mine to have the correct install name, so long > as `DESTDIR=/some/path` is NOT specified upon install. Basically I want to > export the library from both the build tree and the install tree so that > client projects can choose whether or not they want to install the project > (which provides static and dynamic libraries) or just link against it from > the build tree. (If they choose to link against the dylib in the build tree > the this could cause them issues down the road, for example if they `make > clean`, but the implications of linking against a dylib in the build tree > seem fairly obvious.) Right now I am doing this by using the > CMAKE_INSTALL_NAME_DIR variable. I just have the full path to the install > directory in that variable. This way when I build it CMake is smart enough > to use the build tree as the install name, then change it during the > install. However, it would be nice to be able to support DESTDIR. > Is there a way to do this? Or a better way than I am currently doing it? > Should I be building a framework or bundle on mac… the using > `fixup_bundle()` or the like… This seems like overkill for this library, but > maybe it’s the only portable easy way to do this. Or maybe I could call > install_name_tool after the install to ensure that the dylib knows the full > absolute path to itself? I would suggest the following as a better way: Use at least CMake 2.8.12 and in your library project add this: set(CMAKE_MACOSX_RPATH 1) The install name will have @rpath, and the dylib is relieved of the burden of knowing the absolute path to itself, in both the build tree and install tree. The burden is shifted to the client knowing the location of the library it is linking against, which it already knows anyway, but there is another linker flag (-rpath) specifying that path. Clients should also use CMake 2.8.12 or newer. For more details: http://www.kitware.com/blog/home/post/510 Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] good way to append link flags?
On Wednesday, April 23, 2014 06:25:24 PM Nils Gladitz wrote: > On 23.04.2014 18:16, Clinton Stimpson wrote: > > I am using > > set_property(TARGET mytarget APPEND PROPERTY LINK_FLAGS "...") > > multiple times to add various link flags. > > > > But when I inspect the actual link command, I see all my flags separated > > by > > semi-colons and no spaces between them, which is not what I want. > > > > Is this correct behavior for cmake? > > > > Clint > > Try APPEND_STRING (with explicit space) instead of APPEND. > Some flag variables/properties are interpreted as strings rather than lists. > > Nils Oh! Thanks, it works. Clint -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] good way to append link flags?
I am using set_property(TARGET mytarget APPEND PROPERTY LINK_FLAGS "...") multiple times to add various link flags. But when I inspect the actual link command, I see all my flags separated by semi-colons and no spaces between them, which is not what I want. Is this correct behavior for cmake? Clint -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] INTERFACE_LINK_FLAGS ?
Is there a reason for the certain set of INTERFACE_* target properties we have? I have a situation where I'd like to add a /DELAYLOAD linker flag to any project that links against a certain library, but I get a message that INTERFACE_LINK_FLAGS is not supported. Do these INTERFACE_* properties need to be individually handled, or it is as simple as stripping the "INTERFACE_" prefix and applying the properties to consumers? - Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Framework/CFBundle Support
- Original Message - > Hello, > I don't know if I overlook something or the framework/CFBundle support on Mac > OS is rarely. > Most of the things I have already implemented as post-build commands but are > there also CMake ways of doing such things? > .) Adding resources to CFBundles? (Resources for frameworks are supported) > .) Creating PkgInfo files in CFBundles > .) Copying custom Info.plist files to CFBundles With an exception of the 3rd one, I don't think there is a CMake way of doing those except with post-build commands. For the custom Info.plist, have you tried setting the MACOSX_BUNDLE_INFO_PLIST property on the target? Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1
On Thursday, January 16, 2014 03:13:31 PM Dominik Bernhardt wrote: > Hi, > > I just observed, that the current master branch is much slower than > the the release branch with tag 2.8.12.1 > I have built both branches with VS2010 with the Release configuration. > > Does anyone have an idea what might be the cause for that performance > degeneration? Does anyone else observe this behavior? I just tried on Linux and see a slight slowdown there too. On one of my projects, I see ~3.0 seconds for CMake 2.8.12 and ~3.8 seconds for CMake master. I don't have an idea why, but with my test, it doesn't see like "much" slower. Clint -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] missing -rpath-link flag
I have an example (attached) that gives a link error because an -rpath-link flag is missing. If I change the line add_library(static STATIC static.cpp) to add_library(static SHARED static.cpp) then the problem goes away. Also, if I change target_link_libraries(shared2 static) to target_link_libraries(shared2 static sharedb) the problem goes away. I had assumed anything done with target_link_libraries() on static libraries would be pushed up to the shared libraries/executables as needed. But in this case, it doesn't. Is this a bug in CMake? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com test-rpath-link.tar.gz Description: application/compressed-tar -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4: do not prepend CMake root path when searching the mkspecs directory
- Original Message -
> When searching for the mkspecs directory, FindQT4 uses the find_path()
> function, but it doesn't pass the NO_CMAKE_FIND_ROOT_PATH, which means
> that all paths are interpreted relatively to the CMAKE_FIND_ROOT_PATH.
>
> However, both the ${qt_mkspecs_dirs} and ${qt_cross_paths} variable
> that are passed as hints are already absolute paths, and do not need
> to be prepended by the CMAKE_FIND_ROOT_PATH.
>
> Due to this problem, FindQT4 was unable to find qconfig.pri, and
> QT_MKSPECS_DIR was left defined to "NOTFOUND".
>
> Signed-off-by: Thomas Petazzoni
> ---
> Modules/FindQt4.cmake | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
> index 28b8454..0b8ce92 100644
> --- a/Modules/FindQt4.cmake
> +++ b/Modules/FindQt4.cmake
> @@ -760,7 +760,7 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
> endforeach()
> set(QT_MKSPECS_DIR NOTFOUND)
> find_path(QT_MKSPECS_DIR NAMES qconfig.pri
> - HINTS ${qt_cross_paths} ${qt_mkspecs_dirs}
> + HINTS ${qt_cross_paths} ${qt_mkspecs_dirs} NO_CMAKE_FIND_ROOT_PATH
>DOC "The location of the Qt mkspecs containing qconfig.pri")
>endif()
>
Thanks! However, this patch doesn't look complete. You are doing this for the
mkspecs part, but not the plugins and imports part.
To be consistent, can you check those other 2 places too?
Clint
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt4 regression (changing QT_QMAKE_EXECUTABLE)
On Thursday, December 05, 2013 11:33:58 PM Simon Sasburg wrote:
> I've run into a problem after updating my cmake in using the FindQt4 module.
>
> It used to be the case that when QT_QMAKE_EXECUTABLE was changed by the
> user or by a SET(... FORCE) command, all the derived cache entries would be
> refreshed, however this does not work anymore.
>
> The cause seems to be git commit 21123416b4c2d49fe981279b10fbc78c8d07c491
> which removes the following code:
>
> if(QT_QMAKE_EXECUTABLE_LAST)
> string(COMPARE NOTEQUAL "${QT_QMAKE_EXECUTABLE_LAST}"
> "${QT_QMAKE_EXECUTABLE}" QT_QMAKE_CHANGED)
> endif()
> set(QT_QMAKE_EXECUTABLE_LAST "${QT_QMAKE_EXECUTABLE}" CACHE INTERNAL ""
> FORCE)
>
> I've attached a patch that restores this code so this works again, could
> this be included in the next cmake release?
>
> Best regards,
> Simon
Thanks! I noticed this problem recently too.
I've put it in for you.
http://cmake.org/gitweb?p=cmake.git;a=commit;h=4ee3b655
Clint
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] cpack & components problem
I have a situation where I'm generating a NSIS installer and I set CPACK_COMPONENTS_ALL to pick a few components I want to include. I use one component name for all my executables and shared libraries, and there is a 3rd party library (hdf5) that uses a different component name for installing shared libraries. There is not a way to customize the installation of hdf5 to set the component name, and there is there a way to disable the install() commands. I also want to run BundleUtilities to make sure my packages include dependent libraries. To do so, I have to pick a component name to run BundleUtilities with an install() command. But, the problem I have is the NSIS generator separates each component into its own directory and combines the results into the one and final .exe installer. BundleUtilities fails because the files are not in the same directory. Even if I try component groups, the NSIS generator still separates them by component name rather than by group. Can we have the cpack generators be consistent in how the components are installed? I'm thinking of installed components going into the same directory if they are in the same group, or in the same package file. Then, is there a good way to have cpack run a script like BundleUtilities after multiple components are installed in a certain directory? Or should the hdf5 cmake files be modified to allow people to override the install component names? This is what I have done for now. Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing an installation
- Original Message -
> I need to implement a "test" that does an installation of my project into a
> location and then check that all the files indeed got installed or if there
> are any errors during the installation. Is there a "best practice" way of
> achieving this with CMake? Does CMake itself do something like this in their
> own test suite?
>
I'm not sure if there is a best practice for this, but I make a test like this:
add_test(package ${CMAKE_CPACK_COMMAND} -V -C \${CTEST_CONFIGURATION_TYPE}
--config "${CMAKE_BINARY_DIR}/CPackConfig.cmake")
With it being verbose (-V), I can get extra information to show up on cdash in
case there are problems.
I also have additional install commands
install(CODE/SCRIPT ...)
to check if the installation is OK. That includes things like BundleUtilities,
and a test run of the program.
Clint
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why change option in Cmake -GUI does not require re-configuration?
- Original Message - > I downloaded CMake 2.8.12 and faced the following behavior with Cmake -GUI > which can be reproduced if: > After initial configuration click configurations until all options are not > marked as red. > Then change one the options. > Now you are able to click Generate and skip Configure. > This leads to the wrong project file generated , if last changed option was > incompatible with previously set options. > This does not happen with ccmake. , which enforces configuration after any > change. > It looks like as a bug to me. Yes, its a bug. Thanks for reporting and its fixed here. http://cmake.org/gitweb?p=cmake.git;a=commit;h=b5669873 Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unicode path wrecks havoc with VS2013 generator
On Wednesday, November 13, 2013 03:12:13 PM Nagy-Egri Máté Ferenc wrote: > I have changed the encoding as you suggested and the project compiled fine: > > > 1>-- Build started: Project: cmTryCompileExec747919577, Configuration: > Debug Win32 -- 1> Microsoft (R) C/C++ Optimizing Compiler Version > 18.00.21005.1 for x86 1> Copyright (C) Microsoft Corporation. All rights > reserved. > 1> > 1> cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D > "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise > /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec747919577.dir\Debug\\" > /Fd"cmTryCompileExec747919577.dir\Debug\vc120.pdb" /Gd /TC /analyze- > /errorReport:prompt testCCompiler.c 1> > 1> testCCompiler.c > 1> cmTryCompileExec747919577.vcxproj -> > C:\Users\MátéFerenc\SkyDrive\Develop\Active\GridRipper\VS2013\CMakeFiles\CM > akeTmp\Debug\cmTryCompileExec747919577.exe == Build: 1 succeeded, 0 > failed, 0 up-to-date, 0 skipped == > > > If you could issue a patch (2.8.12.2 if I’m not mistaken) that would correct > this bug, that would simply rock. Here is the fix for a future release. http://cmake.org/gitweb?p=cmake.git;a=commit;h=efe3a5dd Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unicode path wrecks havoc with VS2013 generator
to include in the name of the > build directory. For example, buildñ, and run cmake in there pointing to > any source tree. > > > For me, the Visual Studio 9 2008 generator works fine and the project file > reports an encoding of Windows-1252. It fails with the the Visual Studio > 10 generator where the project file reports a utf-8 encoding, but it really > isn't utf-8. So I get errors like this: > C:\...\cmake\buildñ\CMakeFiles\CMakeTmp\cmTryCompileExec926 > 91608.vcxproj(56,110): > error MSB4025: The project file could not be loaded. Invalid character in > the given encoding. Line 56, position 110. > > > > Modifying cmVisualStudio10TargetGenerator.cxx to set the encoding of the > visual studio file to Windows-1252 instead of utf-8 fixes the problem for > me. > > > Clint > -- > > > > 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://www.cmake.org/mailman/listinfo/cmake > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unicode path wrecks havoc with VS2013 generator
- Original Message - > I have tried to open the solution by the IDE itself, but that fails to load > the solution also. It report the same error while trying to load the > projects inside. > Shall I rebuild CMake with the mentioned patch to make it work, or can I hope > of a patch that solves this problem? You can manually edit the visual studio project file to replace "utf-8" with "Windows-1252" (or whatever is appropriate for your language) and load the project in visual studio. If that works, can you please modify cmVisualStudio10TargetGenerator.cxx to change from "utf-8" to "Windows-1252" to see if you can build the rest of your project. Let us know so we can include a fix. Clint > Feladó: clin...@elemtech.com > Elküldve: szombat, 2013. november 9. 7:14 > Címzett: cmake@cmake.org > - Original Message - > > On 11/8/2013 4:48 AM, Nagy-Egri Máté Ferenc wrote: > > > Hi! > > > > > > I have the following issue, which I do not know whether it is an issue > > > of CMake or Visual Studio. When I try to generate a Visual Studio > > > project under a path that contains unicode characters, VS fails to > > > compile the simple test file and thus CMake terminates project > > > generation. Visual Studio does have some issues with projects under > > > unicode paths, but generally things work. (For eg. the C++AMP call tree > > > generator breaks, therefore no C++AMP project can be built in such > > > paths) I develop all my applications in my Skydrive folder which is > > > under the Users folder, and since my name holds unicode characters, I > > > have no control over mw home folder under Win 8 if I have a Live-ID user > > > in the OS. This is what happens: > > Clearly you need to change your name. :) > > > > Can you create a simple project from the IDE in that directory and get > > it to work? > > > > If you run CMake with --debug-trycompile, can you load the solution in > > the CMakeTmp directory from the IDE? > > > This problem can also be reproduced with English as the current language. > Just pick a character between 128 and 256 to include in the name of the build > directory. > For example, buildñ, and run cmake in there pointing to any source tree. > For me, the Visual Studio 9 2008 generator works fine and the project file > reports an encoding of Windows-1252. > It fails with the the Visual Studio 10 generator where the project file > reports a utf-8 encoding, but it really isn't utf-8. > So I get errors like this: > C:\...\cmake\buildñ\CMakeFiles\CMakeTmp\cmTryCompileExec926 > 91608.vcxproj(56,110): > error MSB4025: The project file could not be loaded. Invalid character in > the given encoding. Line 56, position 110. > Modifying cmVisualStudio10TargetGenerator.cxx to set the encoding of the > visual studio file to Windows-1252 instead of utf-8 fixes the problem for > me. > Clint > -- > 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://www.cmake.org/mailman/listinfo/cmake > -- > Powered by www.kitware.com > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unicode path wrecks havoc with VS2013 generator
- Original Message - > On 11/8/2013 4:48 AM, Nagy-Egri Máté Ferenc wrote: > > Hi! > > > > I have the following issue, which I do not know whether it is an issue > > of CMake or Visual Studio. When I try to generate a Visual Studio > > project under a path that contains unicode characters, VS fails to > > compile the simple test file and thus CMake terminates project > > generation. Visual Studio does have some issues with projects under > > unicode paths, but generally things work. (For eg. the C++AMP call tree > > generator breaks, therefore no C++AMP project can be built in such > > paths) I develop all my applications in my Skydrive folder which is > > under the Users folder, and since my name holds unicode characters, I > > have no control over mw home folder under Win 8 if I have a Live-ID user > > in the OS. This is what happens: > Clearly you need to change your name. :) > > Can you create a simple project from the IDE in that directory and get > it to work? > > If you run CMake with --debug-trycompile, can you load the solution in > the CMakeTmp directory from the IDE? > This problem can also be reproduced with English as the current language. Just pick a character between 128 and 256 to include in the name of the build directory. For example, buildñ, and run cmake in there pointing to any source tree. For me, the Visual Studio 9 2008 generator works fine and the project file reports an encoding of Windows-1252. It fails with the the Visual Studio 10 generator where the project file reports a utf-8 encoding, but it really isn't utf-8. So I get errors like this: C:\...\cmake\buildñ\CMakeFiles\CMakeTmp\cmTryCompileExec926 91608.vcxproj(56,110): error MSB4025: The project file could not be loaded. Invalid character in the given encoding. Line 56, position 110. Modifying cmVisualStudio10TargetGenerator.cxx to set the encoding of the visual studio file to Windows-1252 instead of utf-8 fixes the problem for me. Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Changes made for Mac fixup_bundle
BundleUtilities.cmake assumes a bundle layout, which is
App.app/
Contents/
MacOS/
Frameworks/
Instead, you have
install/
bin/TestApp
Frameworks/
MacOS/
Which does not work. You could try overriding the relative placement of
libraries with something like this:
function(gp_item_default_embedded_path_override item path)
set(path @executable_path PARENT_SCOPE)
endfunction()
Or modify the layout of your install tree.
Clint
On Wednesday, October 23, 2013 04:07:01 PM Yoon, Jong Seo wrote:
> The command I pass to fixup_bundle is
>
> fixup_bundle(\"${APPS}\" \"\${QTPLUGINS}\" \"${LIBRARY_DIRS}\")
>
> The arguments printed out is
>
> APPS =
> /Users/jongseoyoon/jsy/crkit/builds/release-1.6_build_2.8.3_2nd/crkit_build
> /install/bin/TestApp QTPLUGINS =
> LIBRARY_DIRS =
> /Users/foo/build/install/itk/lib/InsightToolkit/Users/foo/build/install/vtk
> /lib/vtk-5.6/Users/foo/build/install/qt-4.8.4/Users/foo/build/install/Framew
> orks/vtk-5.6.1/lib//Users/foo/build/install/Frameworks/qt-4.8.4/lib/Users/fo
> o/build/install/Frameworks/InsightToolkit
>
> The QTPLUGINS are empty for both cmake 2.8.3 and cmake 2.8.11.2.
> I don't use QTPLUGINS, but does this need to be not empty?
>
> Regarding the item_substring, that is not a typo. It does come out that way,
> and I tried to find where that is occurring, but I couldn't. Could that be
> the reason by it's failing to execute fixup_bundle?
>
> Thank you so much for helping me out!
>
> Sincerely,
>
> Jong
>
> -Original Message-
> From: Clinton Stimpson [mailto:clin...@elemtech.com]
> Sent: Tuesday, October 22, 2013 5:02 PM
> To: cmake@cmake.org
> Cc: Yoon, Jong Seo
> Subject: Re: [CMake] Changes made for Mac fixup_bundle
>
>
> Is this a typo?
> item_substring='/Users/foo/build /install/MacO'
>
> Can you please post the arguments you are passing to fixup_bundle()? The
> arguments are also printed out, for example: fixup_bundle
>app='/.../cmake/build/Tests/BundleUtilities/testdir2/testbundleutils2'
>libs='/.../cmake/build/Tests/BundleUtilities/testdir2/module2.so'
>dirs='/.../cmake/build/Tests/BundleUtilities'
>
> Clint
>
> On Tuesday, October 22, 2013 05:16:20 PM Yoon, Jong Seo wrote:
> > Hi Everyone,
> >
> > I have a question regarding the changes cmake changes from 2.8.3 to
> > 2.8.4 and above.
> >
> > I am getting this error when I try to make a dmg file for Mac using
> > cmake 2.8.11.2.
> >
> > exe_dotapp_dir/='/Users/foo/build/install/bin/'
> > item_substring='/Users/foo/build /install/MacO'
> > resolved_embedded_item='/Users/foo/build/install/MacOS/libITKBasicFilters.
> > 3. 20.dylib'
> >
> > Install or copy the item into the bundle before calling fixup_bundle.
> > Or maybe there's a typo or incorrect path in one of the args to
> > fixup_bundle?
> >
> > CMake Error at
> > /Users/foo/build/install/cmake/share/cmake-2.8/Modules/BundleUtilities
> > .cmak
> > e:568 (message): cannot fixup an item that is not in the bundle...
> > Call Stack (most recent call first):
> > /Users/foo/build/install/cmake/share/cmake-2.8/Modules/BundleUtilities
> > .cmake
> >
> > :656 (fixup_bundle_item)
> >
> > /Users/foo/build/bingcc/cmake_install.cmake:39
> > (fixup_bundle)
> >
> > The package I am trying to build works for cmake 2.8.3, but the error
> > message above shows up when I try to build it with cmake 2.8.4 and above.
> > Was there any changes to fixup_bundle from cmake 2.8.3 to cmake 2.8.4?
> >
> > Can anyone tell me what the error means?
> >
> > I am making this package with itk 3.20.1, vtk 5.6.1, and qt 4.8.4.
> >
> > Thank you so much for your help!
> >
> > Sincerely,
> >
> > Jong
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio and /STACK
On Friday, October 25, 2013 02:52:45 PM David Cole wrote: > > Hmmm... Well that was a not backward compatible way of doing it. > > This behavior has existed for a long long time. > > Sorry for the extra effort you had to expend tracking down a mysterious > problem because of this change. I remember having some discussions > (probably just verbal, though, I can't find anything in email or bug > tracker) about whether this "simple change" should have a policy, and > we decided not to because we thought "out of stack space" errors would > be relatively easy to identify and correct in projects that require > large stack space. > > Out of curiosity, if you can share details, why did it take so long to > identify the problem in your case? (Or was it immediately obvious, and > you just took that long to trace it back to a CMake change?) > If you were curious... We also ran into this problem with an application. The error dialog that comes up on Windows specifically says stack overflow (at least with a debug build). So for us, it was easy to know that it was a stack overflow problem, but it wasn't clear why one developer had it and the others didn't, until we traced it back to the cmake version. Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake policy CMP0022 error
On Friday, October 25, 2013 08:40:41 AM Stephen Kelly wrote: > Clinton Stimpson wrote: > > I have a target where I do this: > > SET_TARGET_PROPERTIES(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES "") > > to hide 3rd party libraries from the link interface. > > > > When I do > > if(APPLE) > > > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) > > > > endif() > > I get an error at generate time. > > > > This is different than my previous experiences with cmake policies. Based > > on past experiences, I expected to see a warning if I had > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8) > > but used CMake 2.8.12 which introduced CMP0022. > > You might have wrong understanding of policies. > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6d50d0197a5 > > Your use of cmake_minimum_required(VERSION 2.8.12) requests the non-backward > compatible behavior. Yeah, I knew that. I'm trying to point out that I did not get a warning when I was using cmake_minimum_required(VERSION 2.8) set_target_properties(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES "") with CMake 2.8.12. That looks like a bug. > > > But in this case, I don't see a warning. > > The error I get with > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) > > is: > > > > CMake Error in .../CMakeLists.txt: > > Target "mytarget" has policy CMP0022 enabled, but also has old-style > > LINK_INTERFACE_LIBRARIES properties populated, but it was exported > > without the EXPORT_LINK_INTERFACE_LIBRARIES to export the old-style > > properties > > > > When I read the output from cmake --help-policy CMP0022, its not clear to > > me why I'm getting the error. > > 2.8.12 introduced a INTERFACE_LINK_LIBRARIES property, which should be used > instead of LINK_INTERFACE_LIBRARIES. The policy makes the > INTERFACE_LINK_LIBRARIES property ignored until it is set to NEW. > Oh! I somehow missed that the name was changed. INTERFACE_LINK_LIBRARIES -> LINK_INTERFACE_LIBRARIES. I re-read the docs and now I'm wondering how I missed that, duh. Thanks, Clint -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake policy CMP0022 error
I have a target where I do this: SET_TARGET_PROPERTIES(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES "") to hide 3rd party libraries from the link interface. When I do if(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) endif() I get an error at generate time. This is different than my previous experiences with cmake policies. Based on past experiences, I expected to see a warning if I had CMAKE_MINIMUM_REQUIRED(VERSION 2.8) but used CMake 2.8.12 which introduced CMP0022. But in this case, I don't see a warning. The error I get with CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) is: CMake Error in .../CMakeLists.txt: Target "mytarget" has policy CMP0022 enabled, but also has old-style LINK_INTERFACE_LIBRARIES properties populated, but it was exported without the EXPORT_LINK_INTERFACE_LIBRARIES to export the old-style properties When I read the output from cmake --help-policy CMP0022, its not clear to me why I'm getting the error. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Changes made for Mac fixup_bundle
Is this a typo? item_substring='/Users/foo/build /install/MacO' Can you please post the arguments you are passing to fixup_bundle()? The arguments are also printed out, for example: fixup_bundle app='/.../cmake/build/Tests/BundleUtilities/testdir2/testbundleutils2' libs='/.../cmake/build/Tests/BundleUtilities/testdir2/module2.so' dirs='/.../cmake/build/Tests/BundleUtilities' Clint On Tuesday, October 22, 2013 05:16:20 PM Yoon, Jong Seo wrote: > Hi Everyone, > > I have a question regarding the changes cmake changes from 2.8.3 to 2.8.4 > and above. > > I am getting this error when I try to make a dmg file for Mac using cmake > 2.8.11.2. > > exe_dotapp_dir/='/Users/foo/build/install/bin/' > item_substring='/Users/foo/build /install/MacO' > resolved_embedded_item='/Users/foo/build/install/MacOS/libITKBasicFilters.3. > 20.dylib' > > Install or copy the item into the bundle before calling fixup_bundle. > Or maybe there's a typo or incorrect path in one of the args to > fixup_bundle? > > CMake Error at > /Users/foo/build/install/cmake/share/cmake-2.8/Modules/BundleUtilities.cmak > e:568 (message): cannot fixup an item that is not in the bundle... > Call Stack (most recent call first): > /Users/foo/build/install/cmake/share/cmake-2.8/Modules/BundleUtilities.cmake > :656 (fixup_bundle_item) /Users/foo/build/bingcc/cmake_install.cmake:39 > (fixup_bundle) > > The package I am trying to build works for cmake 2.8.3, but the error > message above shows up when I try to build it with cmake 2.8.4 and above. > Was there any changes to fixup_bundle from cmake 2.8.3 to cmake 2.8.4? > > Can anyone tell me what the error means? > > I am making this package with itk 3.20.1, vtk 5.6.1, and qt 4.8.4. > > Thank you so much for your help! > > Sincerely, > > Jong -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake 2.8.12-rc2 FindHDF5 issues
On Thursday, September 19, 2013 01:47:23 PM Brad King wrote: > On 09/17/2013 06:16 PM, Clinton Stimpson wrote: > > I've narrowed it down to a regression caused by 04d4dc33. > > The following should fix this: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0f05961f > > See the commit message for an explanation. > > Please test and let me know. > > Thanks, > -Brad It fixed my simple test case. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.12-rc2 FindHDF5 issues
On Tuesday, September 17, 2013 04:01:30 PM Orion Poplawski wrote:
> On 09/16/2013 09:58 PM, clin...@elemtech.com wrote:
> > Same here... and this looks like a regression:
> >
> > A simple CMakeLists.txt like this can reproduce it.
> >
> > set(CMAKE_BUILD_TYPE Debug)
> > find_package(HDF5 COMPONENTS C HL REQUIRED)
> > add_executable(foo foo.cpp)
> > target_link_libraries(foo ${HDF5_LIBRARIES})
> >
> > FindHDF5.cmake misuses CMAKE_BUILD_TYPE and CMAKE_CONFIGURATION_TYPES when
> > assembling the HDF5_LIBRARIES variable. If I clear out the
> > CMAKE_BUILD_TYPE variable, then the problem goes away.
> >
> > Clint
>
> cmake 2.8.11.2:
>
> -- Found HDF5:
> debug;/usr/lib64/libz.so;debug;/usr/lib64/libdl.so;debug;/usr/lib64/libm.so;
> debug;/usr/lib64/libhdf5_hl.so;debug;/usr/lib64/libhdf5.so;optimized;/usr/li
> b64/libz.so;optimized;/usr/lib64/libdl.so;optimized;/usr/lib64/libm.so;optim
> ized;/usr/lib64/libhdf5_hl.so;optimized;/usr/lib64/libhdf5.so
>
> cmake 2.8.12-rc2:
>
> -- Found HDF5:
> debug;HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_z_LIBRARY_DEBUG-NOTFOUND;d
> ebug;HDF5_dl_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_m_LIBRARY_DEBUG-NOTFOUND;debu
> g;HDF5_hdf5_hl_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND
> ;optimized;/usr/lib64/libz.so;optimized;/usr/lib64/libdl.so;optimized;/usr/l
> ib64/libm.so;optimized;/usr/lib64/libhdf5_hl.so;optimized;/usr/lib64/libhdf5
> .so
>
>
> In comparing the CMakeCache:
[ snip ]
>
> As Rolf noted, FindHDF5 has not changed.
Right, it hasn't changed.
I've narrowed it down to a regression caused by 04d4dc33.
Will Dicharry, is this something you can look at? You are the maintainer for
both FindHDF5 and SelectLibraryConfigurations. A change in
SelectLibraryConfigurations caused a break in FindHDF5.
Clint
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.12-rc2 Released
Same here... and this looks like a regression:
A simple CMakeLists.txt like this can reproduce it.
set(CMAKE_BUILD_TYPE Debug)
find_package(HDF5 COMPONENTS C HL REQUIRED)
add_executable(foo foo.cpp)
target_link_libraries(foo ${HDF5_LIBRARIES})
FindHDF5.cmake misuses CMAKE_BUILD_TYPE and CMAKE_CONFIGURATION_TYPES when
assembling the HDF5_LIBRARIES variable. If I clear out the CMAKE_BUILD_TYPE
variable, then the problem goes away.
Clint
- Original Message -
> On 08/30/2013 02:49 PM, Robert Maynard wrote:
> > The CMake 2.8.12 release candidate stream continues!
> > You can find the source and binaries here:
> > http://www.cmake.org/files/v2.8/?C=M;O=D
>
> Is it expected that this is now an error?
>
> CMake Error: The following variables are used in this project, but they are
> set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake
> files:
> HDF5_dl_LIBRARY_DEBUG (ADVANCED)
> linked by target "netcdf" in directory
> /builddir/build/BUILD/netcdf-c-4.3.1-rc2/liblib
> linked by target "ncgen" in directory
> /builddir/build/BUILD/netcdf-c-4.3.1-rc2/ncgen
> linked by target "nccopy" in directory
> /builddir/build/BUILD/netcdf-c-4.3.1-rc2/ncdump
> linked by target "ncdump" in directory
> /builddir/build/BUILD/netcdf-c-4.3.1-rc2/ncdump
> linked by target "nctestserver" in directory
> /builddir/build/BUILD/netcdf-c-4.3.1-rc2/ncdap_test
>
> Something has definitely changed with handling debug CMAKE_BUILD_TYPEs
> between
> 2.8.11.2 and 2.8.12-rc2. I'm building netcdf 4.8.1-rc2 and it works fine
> with
> 2.8.11.2 but I get errors like the above with 2.8.12-rc2. We build Fedora
> packages with either the Debug or RelWithDebugInfo build types so debug info
> is generated - though it is later stripped and put into a separate -debuginfo
> sub-package. So the debug versions of libraries are generally not available
> at build time.
>
> Could someone describe to me more of what is going on here? There seems to
> be
> a new "debug" link mode or some such? I'm afraid this will be a real show
> stopper for Linux distributions.
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane or...@nwra.com
> Boulder, CO 80301 http://www.nwra.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://www.cmake.org/mailman/listinfo/cmake
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] rpath trouble on macosx: cmake 2.8.9 ignores INSTALL_NAME_DIR and INSTALL_RPATH?
On Tuesday, September 10, 2013 09:43:59 AM Dan Kegel wrote:
> Howdy!
> I'm using 2.8.9 installed on MacOSX using macports, and am trying to get
> a minimal example of rpath working.
>
> Doing it without cmake works fine; see
> http://kegel.com/macosx/rpath/demo.txt
> which just does
> gcc -shared foo.c -install_name @rpath/foo.so -o foo.so
> gcc -Wl,-rpath $OTHERDIR x.c foo.so
> and works fine.
>
> But doing it with cmake eludes me. Here's what I'm trying:
> http://kegel.com/macosx/rpath/demo2.txt
> http://kegel.com/macosx/rpath/CMakeLists.txt
> That CMakeLists.txt is just
>
> cmake_minimum_required(VERSION 2.8)
> set(MYLIBDIR "${CMAKE_SOURCE_DIR}/otherdir")
>
> add_library(foo SHARED foo.c)
> set_target_properties(foo PROPERTIES INSTALL_NAME_DIR "@rpath")
>
> add_executable(x x.c)
> set_target_properties(
> x
> PROPERTIES
> BUILD_WITH_INSTALL_RPATH 1
> INSTALL_RPATH ${MYLIBDIR}
> )
> target_link_libraries(x foo)
>
> When I run demo2.txt, it does
>
> /usr/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -o
> libfoo.dylib -install_name /Users/dank/rpath/btmp/libfoo.dylib
> CMakeFiles/foo.dir/foo.c.o
> /usr/bin/gcc-o CMakeFiles/x.dir/x.c.o -c /Users/dank/rpath/x.c
> /usr/bin/gcc -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names CMakeFiles/x.dir/x.c.o -o x
> libfoo.dylib
>
> and it appears to have totally ignored INSTALL_RPATH,
> so naturally running x fails with
> dyld: Library not loaded: /Users/dank/rpath/btmp/libfoo.dylib
>
> Can I buy a clue, please?
Using the INSTALL_RPATH property doesn't work correctly unless you use CMake
2.8.12 with the target property MACOSX_RPATH=1.
If you want it to work with the older version of CMake, then you need to set
the -Wl,-rpath linker flag yourself using the LINK_FLAGS target property.
set_target_properties(x PROPERTIES LINK_FLAGS "-Wl,-rpath,${MYLIBDIR}")
You should still keep the BUILD_WITH_INSTALL_RPATH=1 if you want the
INSTALL_NAME_DIR=@rpath to be applied at build time instead of waiting until
install time.
Clint
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] rpath trouble on macosx: cmake 2.8.9 ignores INSTALL_NAME_DIR and INSTALL_RPATH?
On Tuesday, September 10, 2013 04:03:08 PM Dan Kegel wrote: > On Tue, Sep 10, 2013 at 10:43 AM, Clinton Stimpson wrote: > > Using the INSTALL_RPATH property doesn't work correctly unless you use > > CMake 2.8.12 with the target property MACOSX_RPATH=1. > > Done, example http://kegel.com/macosx/rpath/demo2/CMakeLists.txt Actually, you want either of these set_target_properties(foo PROPERTIES INSTALL_NAME_DIR "@rpath") or set_target_properties(foo PROPERTIES MACOSX_RPATH 1) There is no need to set it as a property on target x. > > > If you want it to work with the older version of CMake, then you need to > > set the -Wl,-rpath linker flag yourself using the LINK_FLAGS target > > property. > Done, example http://kegel.com/macosx/rpath/demo3/CMakeLists.txt > > Next question: will cmake support relative rpaths, as in the example at > http://kegel.com/macosx/rpath/demo4/demo4.txt ? > i.e. > gcc -shared foo.c -install_name @rpath/lib/foo.so -o foo.so > gcc -Wl,-rpath,@loader_path/.. x.c foo.so > ? (I know, I should download and build trunk, but I'm pathetically lazy.) > - Dan Yes, it'll work in 2.8.12 like this. set_target_properties(x PROPERTIES INSTALL_RPATH "@loader_path/..") Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 03:01:06 PM Laurent Chauvin wrote:
> Thank you for your help Clint.
>
> I identified the problem. When I compile my library with
> CMAKE_MACOSX_RPATH, the library created is linked with
> @rpath/libMyLib.dylib.
> When I was recompiling (make) it was updating the library in the build
> directory but it was not re-installing (copying in the MyLibrary-install
> directory).
> That's why the link was keep failing.
>
> Is there a way to automatically reinstall when recompiling in Cmake ?
Not really.
You can always do a "make install" instead of "make", which will do both the
make and install in one step.
Clint
>
> Thank you very much.
> -Laurent
>
> On Wed, Sep 4, 2013 at 2:16 PM, Clinton Stimpson
wrote:
> > On Wednesday, September 04, 2013 01:22:11 PM Laurent Chauvin wrote:
> > > Does your example still works if you replace this line:
> > >
> > > target_link_libraries(app ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
> > >
> > > by this one:
> > >
> > > target_link_libraries(app lib)
> >
> > No. It doesn't work. I get "ld: library not found for -llib"
> >
> > If I add a link_directories() I can get it working again.
> > If I were to use an export file, it would also work again.
> >
> > Feel free to try experiment with the example I gave you to verify that the
> > library can be found at runtime without setting DYLD_LIBRARY_PATH. You
> > only
> > need to supply 2 .cpp files with some dummy functions. The library and
> > executable are in two separate directories.
> >
> > Clint
> >
> > > ?
> > >
> > > Thank you.
> > > -Laurent
> > >
> > > On Wed, Sep 4, 2013 at 1:18 PM, Clinton Stimpson
> >
> > wrote:
> > > > On Wednesday, September 04, 2013 12:48:41 PM Laurent Chauvin wrote:
> > > > > Yes I'm using 2.8.12-rc2 for the library and the example.
> > > > >
> > > > > But my example is not in the same directory as my library.
> > > >
> > > > Neither was my example.
> > > >
> > > > > I can see in your example you specify the full path in
> > > > > target_link_libraries of your library, which I could probably do.
> > > > >
> > > > > The problem is, if later on my library I want to put the .dyld not
> > > > > in
> > > > > MyLib/lib but MyLib/testLib, then I will have (or users) to modify
> >
> > all
> >
> > > > > their CMakeLists to modify path of the library.
> > > > > That's why I would like not to have to hardcode the library path
> >
> > into my
> >
> > > > > example.
> > > >
> > > > Of course the users shouldn't hard code it. My example was simply
> > > > demonstrating the solution to the problem of locating the shared
> >
> > library
> >
> > > > at
> > > > runtime, which works in 2.8.12-rc2, without setting DYLD_LIBRARY_PATH.
> > > >
> > > > Really, this problem/solution for finding the .dylib at runtime has
> > > > nothing to
> > > > do with whether your target_link_libraries() has a full path or not.
> >
> > Or
> >
> > > > whether you are using LINK_DIRECTORIES or not.
> > > > I just tested with full path vs. LINK_DIRECTORIES, and it makes no
> > > > difference
> > > > to whether the library can be found at runtime.
> > > >
> > > > As an aside, I'm encouraging you to not use LINK_DIRECTORIES.
> > > >
> > > > Clint
> > > >
> > > > > I'm using find_package to find my library, and include the use file,
> > > >
> > > > which
> > > >
> > > > > define the include_directories and link_directories.
> > > > >
> > > > > I also checked the INSTALL(EXPORT ..), here
> >
> > http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cm
> >
> > > > ak>
> > > >
> > > > > e_file but I don't understand what it's doing and how it works.
> > > > >
> > > > > Thank you.
> > > > > -Laurent
> > > > >
> > > > > On Wed, Sep 4, 2013 at 12:26 PM, Clinton Stimpson
> > > >
> > > > wrote:
> > > > > > On Wednesda
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 01:22:11 PM Laurent Chauvin wrote:
> Does your example still works if you replace this line:
>
> target_link_libraries(app ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
>
> by this one:
>
> target_link_libraries(app lib)
No. It doesn't work. I get "ld: library not found for -llib"
If I add a link_directories() I can get it working again.
If I were to use an export file, it would also work again.
Feel free to try experiment with the example I gave you to verify that the
library can be found at runtime without setting DYLD_LIBRARY_PATH. You only
need to supply 2 .cpp files with some dummy functions. The library and
executable are in two separate directories.
Clint
>
> ?
>
> Thank you.
> -Laurent
>
> On Wed, Sep 4, 2013 at 1:18 PM, Clinton Stimpson
wrote:
> > On Wednesday, September 04, 2013 12:48:41 PM Laurent Chauvin wrote:
> > > Yes I'm using 2.8.12-rc2 for the library and the example.
> > >
> > > But my example is not in the same directory as my library.
> >
> > Neither was my example.
> >
> > > I can see in your example you specify the full path in
> > > target_link_libraries of your library, which I could probably do.
> > >
> > > The problem is, if later on my library I want to put the .dyld not in
> > > MyLib/lib but MyLib/testLib, then I will have (or users) to modify all
> > > their CMakeLists to modify path of the library.
> > > That's why I would like not to have to hardcode the library path into my
> > > example.
> >
> > Of course the users shouldn't hard code it. My example was simply
> > demonstrating the solution to the problem of locating the shared library
> > at
> > runtime, which works in 2.8.12-rc2, without setting DYLD_LIBRARY_PATH.
> >
> > Really, this problem/solution for finding the .dylib at runtime has
> > nothing to
> > do with whether your target_link_libraries() has a full path or not. Or
> > whether you are using LINK_DIRECTORIES or not.
> > I just tested with full path vs. LINK_DIRECTORIES, and it makes no
> > difference
> > to whether the library can be found at runtime.
> >
> > As an aside, I'm encouraging you to not use LINK_DIRECTORIES.
> >
> > Clint
> >
> > > I'm using find_package to find my library, and include the use file,
> >
> > which
> >
> > > define the include_directories and link_directories.
> > >
> > > I also checked the INSTALL(EXPORT ..), here
> >
> > http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cm
> > ak>
> > > e_file but I don't understand what it's doing and how it works.
> > >
> > > Thank you.
> > > -Laurent
> > >
> > > On Wed, Sep 4, 2013 at 12:26 PM, Clinton Stimpson
> >
> > wrote:
> > > > On Wednesday, September 04, 2013 12:02:55 PM Laurent Chauvin wrote:
> > > > > Thank you for you help Clint.
> > > > >
> > > > > I actually relinked, but as you said I still had the
> >
> > LINK_DIRECTORIES.
> >
> > > > > However, if I remove it, I have a linking error telling me it cannot
> > > > > find
> > > > > the library.
> > > > >
> > > > > Should I keep the library in Target_Link_Libraries, or with new
> >
> > flags,
> >
> > > > > dependency will automatically find the library ?
> > > >
> > > > You can leave your LINK_DIRECTORIES as its not the cause of your
> >
> > runtime
> >
> > > > failure to find the library.
> > > >
> > > > For compiling MyExample, did you also use CMake 2.8.12 RC?
> > > >
> > > > Here's a minimal example that works for me.
> > > >
> > > > -- lib/CMakeLists.txt
> > > > set(CMAKE_MACOSX_RPATH 1)
> > > > add_library(lib SHARED lib.cpp)
> > > >
> > > > -- app/CMakeLists.txt
> > > > add_executable(app app.cpp)
> > > > target_link_libraries(app
> >
> > ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
> >
> > > > In lib/
> > > > I run "cmake . && make"
> > > >
> > > > In app/
> > > > I run "cmake . && make && ./app"
> > > >
> > > > With 2.8.12, it works.
> > > >
> > > > With an older version, I get
> > > > dyld: Libr
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 12:48:41 PM Laurent Chauvin wrote:
> Yes I'm using 2.8.12-rc2 for the library and the example.
>
> But my example is not in the same directory as my library.
Neither was my example.
>
> I can see in your example you specify the full path in
> target_link_libraries of your library, which I could probably do.
>
> The problem is, if later on my library I want to put the .dyld not in
> MyLib/lib but MyLib/testLib, then I will have (or users) to modify all
> their CMakeLists to modify path of the library.
> That's why I would like not to have to hardcode the library path into my
> example.
Of course the users shouldn't hard code it. My example was simply
demonstrating the solution to the problem of locating the shared library at
runtime, which works in 2.8.12-rc2, without setting DYLD_LIBRARY_PATH.
Really, this problem/solution for finding the .dylib at runtime has nothing to
do with whether your target_link_libraries() has a full path or not. Or
whether you are using LINK_DIRECTORIES or not.
I just tested with full path vs. LINK_DIRECTORIES, and it makes no difference
to whether the library can be found at runtime.
As an aside, I'm encouraging you to not use LINK_DIRECTORIES.
Clint
>
> I'm using find_package to find my library, and include the use file, which
> define the include_directories and link_directories.
>
> I also checked the INSTALL(EXPORT ..), here
> http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmak
> e_file but I don't understand what it's doing and how it works.
>
> Thank you.
> -Laurent
>
> On Wed, Sep 4, 2013 at 12:26 PM, Clinton Stimpson
wrote:
> > On Wednesday, September 04, 2013 12:02:55 PM Laurent Chauvin wrote:
> > > Thank you for you help Clint.
> > >
> > > I actually relinked, but as you said I still had the LINK_DIRECTORIES.
> > > However, if I remove it, I have a linking error telling me it cannot
> > > find
> > > the library.
> > >
> > > Should I keep the library in Target_Link_Libraries, or with new flags,
> > > dependency will automatically find the library ?
> >
> > You can leave your LINK_DIRECTORIES as its not the cause of your runtime
> > failure to find the library.
> >
> > For compiling MyExample, did you also use CMake 2.8.12 RC?
> >
> > Here's a minimal example that works for me.
> >
> > -- lib/CMakeLists.txt
> > set(CMAKE_MACOSX_RPATH 1)
> > add_library(lib SHARED lib.cpp)
> >
> > -- app/CMakeLists.txt
> > add_executable(app app.cpp)
> > target_link_libraries(app ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
> >
> > In lib/
> > I run "cmake . && make"
> >
> > In app/
> > I run "cmake . && make && ./app"
> >
> > With 2.8.12, it works.
> >
> > With an older version, I get
> > dyld: Library not loaded: @rpath/liblib.dylib
> >
> > Referenced from: /app
> > Reason: image not found
> >
> > Trace/BPT trap
> >
> > Clint
> >
> > > Thank you.
> > > -Laurent
> > >
> > > On Wed, Sep 4, 2013 at 11:59 AM, Clinton Stimpson
> >
> > wrote:
> > > > On Wednesday, September 04, 2013 11:53:45 AM Laurent Chauvin wrote:
> > > > > Hello,
> > > > >
> > > > > I just tried to set the MACOSX_RPATH 1 in the top CMakeLists of
> >
> > MyLib,
> >
> > > > and
> > > >
> > > > > when I now do otool -L libMyLib.dyld, I can indeed see
> > > >
> > > > @rpath/libMyLib.dyld.
> > > >
> > > > > However, my executable "MyExample" is still not able to find the
> >
> > library
> >
> > > > at
> > > >
> > > > > runtime. When I do otool -L MyExample, I still have libMyLib.dyld,
> >
> > not
> >
> > > > > @rpath/libMyLib.dyld.
> > > >
> > > > Did you relink MyExamle against the new libMyLib.dylib? CMake doesn't
> > > > modify
> > > > the install names of libraries being linked against, so if otool -L
> > > > MyExample
> > > > still gives "libMyLib.dylib", I'm assuming you didn't relink it.
> >
> > Using a
> >
> > > > cmake generated export file would take care of setting up dependencies
> >
> > so
> >
> > > > the
> > > > relink would happen simply by doing a make. If you use
>
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 12:02:55 PM Laurent Chauvin wrote:
> Thank you for you help Clint.
>
> I actually relinked, but as you said I still had the LINK_DIRECTORIES.
> However, if I remove it, I have a linking error telling me it cannot find
> the library.
>
> Should I keep the library in Target_Link_Libraries, or with new flags,
> dependency will automatically find the library ?
You can leave your LINK_DIRECTORIES as its not the cause of your runtime
failure to find the library.
For compiling MyExample, did you also use CMake 2.8.12 RC?
Here's a minimal example that works for me.
-- lib/CMakeLists.txt
set(CMAKE_MACOSX_RPATH 1)
add_library(lib SHARED lib.cpp)
-- app/CMakeLists.txt
add_executable(app app.cpp)
target_link_libraries(app ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
In lib/
I run "cmake . && make"
In app/
I run "cmake . && make && ./app"
With 2.8.12, it works.
With an older version, I get
dyld: Library not loaded: @rpath/liblib.dylib
Referenced from: /app
Reason: image not found
Trace/BPT trap
Clint
>
> Thank you.
> -Laurent
>
> On Wed, Sep 4, 2013 at 11:59 AM, Clinton Stimpson
wrote:
> > On Wednesday, September 04, 2013 11:53:45 AM Laurent Chauvin wrote:
> > > Hello,
> > >
> > > I just tried to set the MACOSX_RPATH 1 in the top CMakeLists of MyLib,
> >
> > and
> >
> > > when I now do otool -L libMyLib.dyld, I can indeed see
> >
> > @rpath/libMyLib.dyld.
> >
> > > However, my executable "MyExample" is still not able to find the library
> >
> > at
> >
> > > runtime. When I do otool -L MyExample, I still have libMyLib.dyld, not
> > > @rpath/libMyLib.dyld.
> >
> > Did you relink MyExamle against the new libMyLib.dylib? CMake doesn't
> > modify
> > the install names of libraries being linked against, so if otool -L
> > MyExample
> > still gives "libMyLib.dylib", I'm assuming you didn't relink it. Using a
> > cmake generated export file would take care of setting up dependencies so
> > the
> > relink would happen simply by doing a make. If you use LINK_DIRECTORIES,
> > you
> > miss the relink dependency.
> >
> > Clint
> >
> > > And I have same error (Library not loaded, image not found) when trying
> >
> > to
> >
> > > start the example.
> > >
> > > Should I add something more (or remove something) from my CMakeLists
> > > example ?
> > >
> > > I'm sorry I'm not really familiar with these mechanisms.
> > >
> > > Thank you very much.
> > > -Laurent
> > >
> > >
> > > On Wed, Sep 4, 2013 at 11:30 AM, Laurent Chauvin
> > >
> > > wrote:
> > > > Thank you very much for your answer.
> > > >
> > > > I will try to use the MACOSX_RPATH.
> > > >
> > > > However, I have some questions. As the flag suggests, it's only for
> >
> > mac.
> >
> > > > Is there anything similar for Linux (and eventually Windows systems) ?
> > > >
> > > > Also, the problem to set the full path of the library is, if I compile
> >
> > on
> >
> > > > Windows the extension of library will be dll, on Mac it will be dyld,
> >
> > and
> >
> > > > .a on linux.
> > > > I could make a condition to set the extension at the end of the name
> > > > of
> > > > the library like libMyLib.(dll, dyld, a) but, I feel like it's not
> >
> > really
> >
> > > > a
> > > > clean way to do it.
> > > >
> > > > Is there a better way to do it ?
> > > >
> > > > Thank you very much.
> > > > -Laurent
> > > >
> > > > On Wed, Sep 4, 2013 at 10:57 AM, Clinton Stimpson
> >
> > wrote:
> > > >> On Tuesday, September 03, 2013 09:47:45 PM Laurent Chauvin wrote:
> > > >> > Hello everyone,
> > > >> >
> > > >> > I'm working on a library, and I would like the users be able to
> >
> > create
> >
> > > >> their
> > > >>
> > > >> > own program and liking to my library (by specifying path in cmake).
> > > >> >
> > > >> > I created the library and an example to test it.
> > > >> > Everything compiles.
> > > >> >
> > > >> > However, when I
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 11:30:51 AM Laurent Chauvin wrote:
> Thank you very much for your answer.
>
> I will try to use the MACOSX_RPATH.
>
> However, I have some questions. As the flag suggests, it's only for mac. Is
> there anything similar for Linux (and eventually Windows systems) ?
For Linux, the rpath feature for shared libraries already works well, but it
appears you are actually making static library on Linux. For Mac, the
equivalent of that Linux/Unix rpath feature was added to CMake 2.8.12.
For Windows, if there is a DLL, users of a dll commonly edit their PATH
environment variable to help find it at runtime. There really isn't anything
you as the author of the dll can do to help that.
>
> Also, the problem to set the full path of the library is, if I compile on
> Windows the extension of library will be dll, on Mac it will be dyld, and
> .a on linux.
> I could make a condition to set the extension at the end of the name of the
> library like libMyLib.(dll, dyld, a) but, I feel like it's not really a
> clean way to do it.
>
> Is there a better way to do it ?
Yes, there is a better way. Use install(EXPORT ..), which will take care of
those details for you.
Your MyLibConfig.cmake/mylib-config.cmake file can include it.
Clint
>
> Thank you very much.
> -Laurent
>
> On Wed, Sep 4, 2013 at 10:57 AM, Clinton Stimpson
wrote:
> > On Tuesday, September 03, 2013 09:47:45 PM Laurent Chauvin wrote:
> > > Hello everyone,
> > >
> > > I'm working on a library, and I would like the users be able to create
> >
> > their
> >
> > > own program and liking to my library (by specifying path in cmake).
> > >
> > > I created the library and an example to test it.
> > > Everything compiles.
> > >
> > > However, when I try to run my example I have this error:
> > >
> > > MyExample:
> > > libMyLib.1.dylib (compatibility version 1.0.0, current version
> >
> > 1.0.0)
> >
> > > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> >
> > version
> >
> > > 56.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> > > version 169.3.0)
> > >
> > > The problem is my example is not in the same directory as my library
> > > (not
> > > even in a subdirectory). And it seems it's linking to my library with a
> > > relative path.
> > >
> > > If I add the path of my library in DYLD_LIBRARY_PATH it works, but I
> >
> > would
> >
> > > like the users to be able to compile and link straight forward.
> > >
> > > To link the library to my example I use find_package(MyLib REQUIRED) and
> > > include(${MyLib_USE_FILE}) which basically do a LINK_DIRECTORIES with
> > > the
> > > absolute path of the library.
> > >
> > > Then I do add_executable and target_link_libraries(MyExample
> > > ${MyLib_LIBRARIES})
> > >
> > > Compilation is working fine. There is these options:
> > >
> > > -L/Absolute/Path/To/MyLib -lMyLib
> > >
> > > But at runtime, library cannot be found.
> > >
> > > Would it be possible to put the full path of my library when linking in
> >
> > the
> >
> > > CMakeLists ?
> >
> > You should use the full path to the library instead of LINK_DIRECTORIES.
> > Its easiest if you use install(EXPORT ...) to have CMake generate an
> > export
> > file for you that can be included by your FindMyLib.cmake file.
> > That export file will use the full path, and include any other necessary
> > information about the library.
> >
> > But to solve the problem of finding the library at runtime (specifying a
> > full
> > path won't solve it), CMake 2.8.12 has a new feature to address exactly
> > that
> > problem. For details: http://www.kitware.com/blog/home/post/510
> >
> > If you can use CMake 2.8.12, then you need to put
> >
> > set(MACOSX_RPATH 1)
> >
> > in the CMakeLists.txt of MyLib.
> >
> > If the user is using 2.8.12, then any executable they compile with your
> > library will be able to find the library, no matter where it is.
> >
> > By the way, 2.8.12 is in a release candidate stage right now, and right
> > now
> > would be a good time for you to test the new feature that is meant to
> > solve
> > your problem.
> >
> > Clint
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 11:53:45 AM Laurent Chauvin wrote:
> Hello,
>
> I just tried to set the MACOSX_RPATH 1 in the top CMakeLists of MyLib, and
> when I now do otool -L libMyLib.dyld, I can indeed see @rpath/libMyLib.dyld.
> However, my executable "MyExample" is still not able to find the library at
> runtime. When I do otool -L MyExample, I still have libMyLib.dyld, not
> @rpath/libMyLib.dyld.
Did you relink MyExamle against the new libMyLib.dylib? CMake doesn't modify
the install names of libraries being linked against, so if otool -L MyExample
still gives "libMyLib.dylib", I'm assuming you didn't relink it. Using a
cmake generated export file would take care of setting up dependencies so the
relink would happen simply by doing a make. If you use LINK_DIRECTORIES, you
miss the relink dependency.
Clint
> And I have same error (Library not loaded, image not found) when trying to
> start the example.
>
> Should I add something more (or remove something) from my CMakeLists
> example ?
>
> I'm sorry I'm not really familiar with these mechanisms.
>
> Thank you very much.
> -Laurent
>
>
> On Wed, Sep 4, 2013 at 11:30 AM, Laurent Chauvin
>
> wrote:
> > Thank you very much for your answer.
> >
> > I will try to use the MACOSX_RPATH.
> >
> > However, I have some questions. As the flag suggests, it's only for mac.
> > Is there anything similar for Linux (and eventually Windows systems) ?
> >
> > Also, the problem to set the full path of the library is, if I compile on
> > Windows the extension of library will be dll, on Mac it will be dyld, and
> > .a on linux.
> > I could make a condition to set the extension at the end of the name of
> > the library like libMyLib.(dll, dyld, a) but, I feel like it's not really
> > a
> > clean way to do it.
> >
> > Is there a better way to do it ?
> >
> > Thank you very much.
> > -Laurent
> >
> > On Wed, Sep 4, 2013 at 10:57 AM, Clinton Stimpson
wrote:
> >> On Tuesday, September 03, 2013 09:47:45 PM Laurent Chauvin wrote:
> >> > Hello everyone,
> >> >
> >> > I'm working on a library, and I would like the users be able to create
> >>
> >> their
> >>
> >> > own program and liking to my library (by specifying path in cmake).
> >> >
> >> > I created the library and an example to test it.
> >> > Everything compiles.
> >> >
> >> > However, when I try to run my example I have this error:
> >> >
> >> > MyExample:
> >> > libMyLib.1.dylib (compatibility version 1.0.0, current version
> >>
> >> 1.0.0)
> >>
> >> > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> >>
> >> version
> >>
> >> > 56.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> >> > current
> >> > version 169.3.0)
> >> >
> >> > The problem is my example is not in the same directory as my library
> >>
> >> (not
> >>
> >> > even in a subdirectory). And it seems it's linking to my library with a
> >> > relative path.
> >> >
> >> > If I add the path of my library in DYLD_LIBRARY_PATH it works, but I
> >>
> >> would
> >>
> >> > like the users to be able to compile and link straight forward.
> >> >
> >> > To link the library to my example I use find_package(MyLib REQUIRED)
> >> > and
> >> > include(${MyLib_USE_FILE}) which basically do a LINK_DIRECTORIES with
> >>
> >> the
> >>
> >> > absolute path of the library.
> >> >
> >> > Then I do add_executable and target_link_libraries(MyExample
> >> > ${MyLib_LIBRARIES})
> >> >
> >> > Compilation is working fine. There is these options:
> >> >
> >> > -L/Absolute/Path/To/MyLib -lMyLib
> >> >
> >> > But at runtime, library cannot be found.
> >> >
> >> > Would it be possible to put the full path of my library when linking in
> >>
> >> the
> >>
> >> > CMakeLists ?
> >>
> >> You should use the full path to the library instead of LINK_DIRECTORIES.
> >> Its easiest if you use install(EXPORT ...) to have CMake generate an
> >> export
> >> file for you that can be included by your FindMyLib.cmake file.
> >> That export
Re: [CMake] Absolute Path linking library
On Tuesday, September 03, 2013 09:47:45 PM Laurent Chauvin wrote:
> Hello everyone,
>
> I'm working on a library, and I would like the users be able to create their
> own program and liking to my library (by specifying path in cmake).
>
> I created the library and an example to test it.
> Everything compiles.
>
> However, when I try to run my example I have this error:
> MyExample:
> libMyLib.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
> 56.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 169.3.0)
>
> The problem is my example is not in the same directory as my library (not
> even in a subdirectory). And it seems it's linking to my library with a
> relative path.
>
> If I add the path of my library in DYLD_LIBRARY_PATH it works, but I would
> like the users to be able to compile and link straight forward.
>
> To link the library to my example I use find_package(MyLib REQUIRED) and
> include(${MyLib_USE_FILE}) which basically do a LINK_DIRECTORIES with the
> absolute path of the library.
>
> Then I do add_executable and target_link_libraries(MyExample
> ${MyLib_LIBRARIES})
>
> Compilation is working fine. There is these options:
>
> -L/Absolute/Path/To/MyLib -lMyLib
>
> But at runtime, library cannot be found.
>
> Would it be possible to put the full path of my library when linking in the
> CMakeLists ?
>
You should use the full path to the library instead of LINK_DIRECTORIES.
Its easiest if you use install(EXPORT ...) to have CMake generate an export
file for you that can be included by your FindMyLib.cmake file.
That export file will use the full path, and include any other necessary
information about the library.
But to solve the problem of finding the library at runtime (specifying a full
path won't solve it), CMake 2.8.12 has a new feature to address exactly that
problem. For details: http://www.kitware.com/blog/home/post/510
If you can use CMake 2.8.12, then you need to put
set(MACOSX_RPATH 1)
in the CMakeLists.txt of MyLib.
If the user is using 2.8.12, then any executable they compile with your
library will be able to find the library, no matter where it is.
By the way, 2.8.12 is in a release candidate stage right now, and right now
would be a good time for you to test the new feature that is meant to solve
your problem.
Clint
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] One build, multiple compilers and packages
- Original Message - > Hi. First, apologies for the length. If you are not interested in mixing > different compilers and generating multiple packages all within one build, > you can probably stop reading now. > After trying various approaches and not being entirely satisfied with any, I > thought I'd seek the collective wisdom on this list. The details below > define the scenario, the main problems faced and some things that have been > tried to address them. Comments, ideas or suggestions would be most welcome. > SCENARIO: > We have a large code base for which different components need to be built > with different compilers. Some parts are desktop software (applications, > libraries) and others are firmware for embedded devices. All are pulled > together into a small number of packages using CPack. Some of those packages > share common items and there is no correlation between compilers and > packages. Most items are included in more than one of the packages. For > instance, firmware might be included in all packages, a particular desktop > application or library in a subset of the packages, etc. On a given > platform, some packages will have one format and other packages will have a > different format (eg a mix of RPM and tarball). We create packages for at > least Windows and Linux. > Most of the source code is in a single git repository and after testing > different strategies, this is an arrangement we want to keep. There are a > couple of components being built using CMake's ExternalProject feature, > either because they use a different build system that is currently too > complex for us to change to CMake or the source code comes from a 3rd party. > PROBLEMS: > 1. CMake assumes you only want to use one compiler for an entire build tree. > 2. CPack assumes you are only building one package. Some package generators > allow you to do a component-based setup where multiple packages can be > generated, but this is not supported for all package generators (eg the NSIS > package generator won't produce multiple packages). > APPROACHES TRIED (feedback welcome): > The first of the above two issues is the more problematic. I've spent > considerable time experimenting with ExternalProject as a potential way of > addressing various issues, including the "one compiler per build tree" > restriction. What I found was that dependency handling and integration with > CPack becomes much more complicated, and in some cases has deficiencies not > present in a single unified CMake build. For example, once you have > successfully built an external project, the top level build won't rebuild it > again unless something about its configuration changes. Thus, if you > subsequently make changes to a source file, simply building the top level > project won't work because it still thinks the sub project is up to date. > This is because ExternalProject uses time stamps rather than forwarding the > build request to the sub project to let it decide if anything needs to be > built. This kinda makes sense, since an ExternalProject is meant to > encompass everything from download through to install, but this is not how > we are trying (and needing) to use it. ExternalProject starts to become less > useful when applied to source code you are actively working on. > Effectively, what we really need is the ability to let add_subdirectory() > create a whole new build with a potentially different compiler, but still > have it aware of all the other targets and dependencies and also to > propagate all its own the targets, dependencies, etc. up to the parent. We > experimented with exporting targets from the ExternalProject's using the > export features of the install command, but this was messy and ultimately > still suffers from the "isn't aware of changes to the source" problem. It > also has implications for stripping of targets (for an example, see > http://public.kitware.com/Bug/view.php?id=14157 ). Packaging also gets much > more cumbersome when ExternalPackage is involved. > For the second problem, my current workaround is to create a custom target > which re-configures and re-builds the project for each package I need to > create. The targets only need to get built once, but the package details > change each time and a different package gets built. In essence, the build > calls itself with a set of different configurations, which seemed a bit > mind-bending at first, but was fairly simple to implement and didn't seem to > have much in the way of negative side effects. The approach works reliably, > but it feels like a roundabout solution to something that CMake/CPack should > be able to handle much more cleanly. In a similar vein to the suggestion > above, it would be really nice if add_subdirectory() had the ability to > define a package that was not affected or did not affect other directories. > Thus, you could have one package per sub directory. Any common variables > could be defined at the parent level and w
Re: [CMake] syntax error?
On Wednesday, August 14, 2013 04:25:10 PM David Cole wrote:
> > I'm using cmake from git master as of today and it gives me a warning
> >
> > CMake Warning (dev) in .../CMakeLists.txt:
> > Syntax Warning in cmake code at
> >
> > /.../CMakeLists.txt:309:10
>
> I do not get an error with this CMakeLists.txt:
>
> cmake_minimum_required(VERSION 2.8)
> project(xyz NONE)
>
> message("MSVC='${MSVC}'")
> message("MSVC_VERSION='${MSVC_VERSION}'")
>
> if (NOT (MSVC AND (MSVC_VERSION EQUAL 1600)))
> message("true")
> else()
> message("false")
> endif()
>
>
> I tried with 2.8.11.2 and 'nightly' -- does anybody else see a problem
> with this? Is it possibly something in 'master' that has already been
> fixed in 'nightly'?
>
> However, MSVC is empty unless I remove the "NONE" from project...
>
>
> HTH,
> D
Ah, you introduced a space after the "NOT" to silence the warning.
I'm not sure why it is picky about that space not being there.
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.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://www.cmake.org/mailman/listinfo/cmake
[CMake] syntax error?
Is the following a syntax error? if (NOT(MSVC AND (MSVC_VERSION EQUAL 1600))) ... I'm using cmake from git master as of today and it gives me a warning CMake Warning (dev) in .../CMakeLists.txt: Syntax Warning in cmake code at /.../CMakeLists.txt:309:10 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MacOS bundle using MACOS_PACKAGE_LOCATION with XCode - files not copied
- Original Message -
> Hello,
>
> I'm using cmake to generate an Xcode project which is supposed to build a
> bundle. Thus, I use the source file property MACOSX_PACKAGE_LOCATION to
> place my data (database, GUI, localization files, …) in the correct
> directory in my bundle.
>
> I used to have a general CMakeLists.txt with several commands like follows:
>
> file(GLOB VAR_GUI
> ${RESOURCE_PATH}/GUI/*
> )
> set_source_files_properties(
> ${VAR_GUI}
> PROPERTIES
> MACOSX_PACKAGE_LOCATION Resources/GUI
> )
>
> Then one command to concatenate all the independent variables (used to
> separate the different directories)
> set(RESOURCES "${VAR_GUI};…")
>
> Finally, in my main CMakeLists.txt i wrote :
> add_executable(${CMAKE_PROJECT_NAME} MACOSX_BUNDLE ${SOURCES} ${HEADERS}
> ${RESOURCES})
>
> So every data of my project was more or else added by hand. I wanted to
> automated the process so i wrote a python script that does the job for me.
> The script proceeds by writing a file in which each directory of my resource
> directory has its own variable listing the files in it (semi-colon separated
> element list). It also generate a set of 'source_group' command to organize
> resources in the IDE.
> The generated file is included in my main CMakeLists.txt using the 'include'
> command.
>
> The generated file use commands like follows:
>
> set(RESOURCE_GUI
> ;;…
> )
>
> set_source_files_properties(
> ${RESOURCE_GUI}
> PROPERTIES
> MACOSX_PACKAGE_LOCATION Resources/GUI
> )
>
> Unfortunately, with this new generated included file, the resources are
> successfully added to the Xcode project but when I build the project, the
> resources are no longer copied into the bundle.
>
> I checked that the include command wasn't the issue since my old commands
> (hand written) works when i put them in the included file (in place of the
> generated commands).
> Trying to figure out the issue, I notice that in Xcode, the only difference
> between resources added by my generated file and the old ones is that the
> old commands were in the end marking my resources file as target member
> (target membership is checked in Xcode). With the generated file, the
> resources are in the project but not marked as member of the target.
> I thought maybe the 'file' command was setting other source file properties
> like EXTERNAL_OBJECT so i tried setting it up by hand, but it doesn't work
> either.
Does your add_executable() include ${RESOURCE_GUI} after your changes?
Clint
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
. Only on windows is a debug > > library required for regular development because of the configuration > > specific C/C++ runtime libraries. > > > > If I made a framework for other people to use, and if for some reason they > > wanted to debug my framework, they could simply compile a debug only > > version and link with that. So I don't see a big need for both a release > > and debug framework. > > Closed source is not common/relevant? For closed source, they could gather some meaningful information with a debug framework. Having a foo.framework/Versions/A/foo foo.framework/Versions/A/foo_debug would be a quick way for them to debug by setting DYLD_IMAGE_SUFFIX=_debug. That's certainly quicker than recompiling their app against a debug framework in a different location. But, if I chose to give them this: Release/foo.framework/Versions/A/foo Debug/foo.framework/Versions/A/foo and their debug build was already linked with the debug foo framework, then debugging can already be done without setting any environment variable to tell the dynamic loader to use a different library. There are a few options here. > > > In the past, when I've had to debug the Qt libraries > > on Mac, I've either made a debug only build, or modified the frameworks. > > The modification was because Qt uses the same "_debug" suffix as the whole > > system, and I don't want the debug version of all of the system libraries > > because it is way too slow. So anyway, for me, this is a very low > > priority problem compared to other cmake issues. > > Right. > > The reporter at https://bugreports.qt-project.org/browse/QTBUG-30938 raises > a reason that DYLD_IMAGE_SUFFIX doesn't work for him anyway. I wonder what > qmake does here. > qmake links your apps against the framework (which under the covers means it is linked with the release Qt libraries), even for a debug build of your application. CMake and qmake behave the same here when developing a Qt based app. The DYLD_IMAGE_SUFFIX approach that works with Qt is to modify the Qt frameworks and rename the _debug files to _qtdebug. Then I set DYLD_IMAGE_SUFFIX=_qtdebug when running the application to debug the Qt libraries without debugging all system libraries (some of which are broken depending on the OS X version). -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
- Original Message - > clin...@elemtech.com wrote: > > > > > > > - Original Message - > >> clin...@elemtech.com wrote: > >> > >> > > >> > > >> > - Original Message - > >> >> Stephen Kelly wrote: > >> >> > >> >> > Is it possible to build multi-config frameworks with cmake at all? > >> >> > >> >> I also notice that the Framework unit test uses > >> >> > >> >> set_target_properties(foo PROPERTIES > >> >>FRAMEWORK TRUE > >> >>DEBUG_POSTFIX -d > >> >> ) > >> >> > >> >> but the debug file is called 'foo', not 'foo-d'. If I use > >> >> > >> >> cmake --build . --target install --config Debug > >> >> cmake --build . --target install --config Release > >> >> > >> >> the debug and release versions overwrite each other. > >> >> > >> >> Does this mean it has always been broken? Has no one ever tried to > >> >> create a framework using cmake? > >> > > >> > In the build tree, I would expect "foo" not "foo-d" for the debug > >> > framework. > >> > And in the build tree, it is possible to differentiate the release from > >> > debug simply by having two "foo.framework/foo". One will be in the > >> > Release folder and one in the Debug folder, and a Debug build will use > >> > the one from the Debug folder, while the release build will use the one > >> > from the Release folder. > >> > >> That indeed appears to be what happens. > > > > But, I personally don't see a problem with there being a > > "foo.framework/foo" and a "foo-d.framework/foo-d". At install time, they > > would not overwrite each other and the export file would need to list both > > of them. > > Or > > Release/foo.framework/foo > Debug/foo.framework/foo-d Ok, but the framework version of the linker flags -L,-l are used like this: -F/path/to/framework -framework foo which result in the linker would look for this file /path/to/framework/foo.framework/foo So, Debug/foo.framework/foo-d is not a valid framework. > > for a presumably smaller change. I don't know about export(), but > install(EXPORT) is already fine. It installs multiple targets-.cmake > files, where each one would reference the correct > IMPORTED_LOCATION_. I just assumed that was already implemented. > > You might be able to tell me if there's some other location/file in a > framework that would break though? (update: I think I understood below) See the case above. > > >> > For the install tree, I don't see how it is known which configurations > >> > will be installed. > >> > >> I'm not familiar with xcode, so I assumed that if you install it would > >> install all configurations, or you would specify which you want to > >> install. > > > > Xcode works in one configuration at a time. > > The install target is the same way, by installing only one configuration > > at a time. > > Ok, so you specify the configuration you want *this time? Then the > configuration is known, right? We don't need to know all configurations that > will be installed because of the multiple targets files. > > >> When I use the command line I use > >> > >> cmake --build . --target install --config Debug > >> > >> so it is specified. > > > > That one configuration was specified, yes. But it isn't known if the > > Release one will also be installed. > > > If it is known they are both being > > installed, and one wanted them to both go into the same framework, then > > the debug one can be renamed to and the burden put on the user to specify > > DYLD_IMAGE_SUFFIX to run their application with the debug library. > > "renamed to foo_debug" ? I don't know for certain, but it seems that that is > the common way of creating these things, right? > > > If only > > the Debug configuration is installed, and it was still renamed, you'd have > > a broken framework. > > Ah, I think I understand now. > > If I install both debug and release, then I get > > foo.framework/foo > foo.framework/foo_debug > > but if I install only the debug version, then I get only > > foo.framework/foo_debug > > And, you're saying that the framework system is not smart enough to work > with that because the non-_debug version is missing? It doesn't just append > the DYLD_IMAGE_SUFFIX on the name of the framework, and after locating the > framework use that as the name of the file? With the -F/-framework link flags, the linker looks for "foo.framework/foo" The DYLD_* variables are used by the dynamic loader at runtime and do not affect the linker. > > >> > >> So, I don't know what you mean here. Can you be more specific, keeping in > >> mind I don't know xcode? > > > > The behavior is basically the same as visual studio, if you know that, > > I'm afraid I never used it extensively or for c++. > > > with the addition of this framework concept. While the whole build system > > supports multiple configurations, the user is only in one configuration at > > a given time. > > ... and the user can only install/create their own frameworks as one > configuration at a time? The
Re: [CMake] Building multiple configurations with Xcode?
- Original Message - > > > - Original Message - > > clin...@elemtech.com wrote: > > > > > > > > > > > - Original Message - > > >> Stephen Kelly wrote: > > >> > > >> > Is it possible to build multi-config frameworks with cmake at all? > > >> > > >> I also notice that the Framework unit test uses > > >> > > >> set_target_properties(foo PROPERTIES > > >>FRAMEWORK TRUE > > >>DEBUG_POSTFIX -d > > >> ) > > >> > > >> but the debug file is called 'foo', not 'foo-d'. If I use > > >> > > >> cmake --build . --target install --config Debug > > >> cmake --build . --target install --config Release > > >> > > >> the debug and release versions overwrite each other. > > >> > > >> Does this mean it has always been broken? Has no one ever tried to > > >> create > > >> a framework using cmake? > > > > > > In the build tree, I would expect "foo" not "foo-d" for the debug > > > framework. > > > And in the build tree, it is possible to differentiate the release from > > > debug simply by having two "foo.framework/foo". One will be in the > > > Release folder and one in the Debug folder, and a Debug build will use > > > the > > > one from the Debug folder, while the release build will use the one from > > > the Release folder. > > > > That indeed appears to be what happens. > > But, I personally don't see a problem with there being a "foo.framework/foo" > and a "foo-d.framework/foo-d". > At install time, they would not overwrite each other and the export file > would need to list both of them. > > > > > > > > > For the install tree, I don't see how it is known which configurations > > > will be installed. > > > > I'm not familiar with xcode, so I assumed that if you install it would > > install all configurations, or you would specify which you want to install. > > Xcode works in one configuration at a time. > The install target is the same way, by installing only one configuration at a > time. > > > > > When I use the command line I use > > > > cmake --build . --target install --config Debug > > > > so it is specified. > > That one configuration was specified, yes. But it isn't known if the Release > one will also be installed. > If it is known they are both being installed, and one wanted them to both go > into the same framework, then the debug one can be renamed to and the burden > put on the user to specify DYLD_IMAGE_SUFFIX to run their application with > the debug library. > If only the Debug configuration is installed, and it was still renamed, you'd > have a broken framework. > > > > > So, I don't know what you mean here. Can you be more specific, keeping in > > mind I don't know xcode? > > The behavior is basically the same as visual studio, if you know that, with > the addition of this framework concept. > While the whole build system supports multiple configurations, the user is > only in one configuration at a given time. > In contrast, building Qt can be done with makefiles that compile multiple > configurations at the same time, but in practice, that kind of setup seems > rare. > > > > > Assuming there is some unavoidable reason that the configuration is not > > known when installing, does that mean that frameworks which contain a foo > > and a foo_debug can not be created by cmake? > > Yeah, that would seem to be the case. Unless someone has done it and can > tell us how. > Again, I wouldn't mind having a foo.framework/foo and foo-d.framework/foo-d > which avoids this whole problem. > Actually, I just realized a foo-d.framework/foo-d introduces another problem. In the code, you'd have to do a #include for a debug build and a #include for a release build, which I wouldn't want. Clint -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
- Original Message - > clin...@elemtech.com wrote: > > > > > > > - Original Message - > >> Stephen Kelly wrote: > >> > >> > Is it possible to build multi-config frameworks with cmake at all? > >> > >> I also notice that the Framework unit test uses > >> > >> set_target_properties(foo PROPERTIES > >>FRAMEWORK TRUE > >>DEBUG_POSTFIX -d > >> ) > >> > >> but the debug file is called 'foo', not 'foo-d'. If I use > >> > >> cmake --build . --target install --config Debug > >> cmake --build . --target install --config Release > >> > >> the debug and release versions overwrite each other. > >> > >> Does this mean it has always been broken? Has no one ever tried to create > >> a framework using cmake? > > > > In the build tree, I would expect "foo" not "foo-d" for the debug > > framework. > > And in the build tree, it is possible to differentiate the release from > > debug simply by having two "foo.framework/foo". One will be in the > > Release folder and one in the Debug folder, and a Debug build will use the > > one from the Debug folder, while the release build will use the one from > > the Release folder. > > That indeed appears to be what happens. But, I personally don't see a problem with there being a "foo.framework/foo" and a "foo-d.framework/foo-d". At install time, they would not overwrite each other and the export file would need to list both of them. > > > > > For the install tree, I don't see how it is known which configurations > > will be installed. > > I'm not familiar with xcode, so I assumed that if you install it would > install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. > > When I use the command line I use > > cmake --build . --target install --config Debug > > so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. > > So, I don't know what you mean here. Can you be more specific, keeping in > mind I don't know xcode? The behavior is basically the same as visual studio, if you know that, with the addition of this framework concept. While the whole build system supports multiple configurations, the user is only in one configuration at a given time. In contrast, building Qt can be done with makefiles that compile multiple configurations at the same time, but in practice, that kind of setup seems rare. > > Assuming there is some unavoidable reason that the configuration is not > known when installing, does that mean that frameworks which contain a foo > and a foo_debug can not be created by cmake? Yeah, that would seem to be the case. Unless someone has done it and can tell us how. Again, I wouldn't mind having a foo.framework/foo and foo-d.framework/foo-d which avoids this whole problem. > > I left a comment on the original Qt bug above that he should look into using > DYLD_IMAGE_SUFFIX. Is that right? That is the correct response in the context of Qt. Clint -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
- Original Message - > Stephen Kelly wrote: > > > Is it possible to build multi-config frameworks with cmake at all? > > I also notice that the Framework unit test uses > > set_target_properties(foo PROPERTIES >FRAMEWORK TRUE >DEBUG_POSTFIX -d > ) > > but the debug file is called 'foo', not 'foo-d'. If I use > > cmake --build . --target install --config Debug > cmake --build . --target install --config Release > > the debug and release versions overwrite each other. > > Does this mean it has always been broken? Has no one ever tried to create a > framework using cmake? In the build tree, I would expect "foo" not "foo-d" for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two "foo.framework/foo". One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. For the install tree, I don't see how it is known which configurations will be installed. If there was some way to know both Release and Debug were going to be installed, then it could be known at that point to rename the debug file to "foo-d". Clint -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BundleUtilities and @rpath
On Wednesday, April 24, 2013 06:45:11 PM Jean-Christophe Fillion-Robin wrote: > Hi Folks, > > I have been working on improving BundleUtilities and GetPrerequisites > module so that it can be used to easily fixup a MacOSX bundle using @rpath. > > The set of changes I would like to propose is here: > https://github.com/jcfr/CMakeBundleUtilitiesExample/compare/f7a594ffba72b8cb > 83df9a166d7887bedc49f38b...75fa538 > > To try out the change, you could build the small project I created for that > purpose: https://github.com/jcfr/CMakeBundleUtilitiesExample#readme > > Let me know what you think. > > Thanks > Jc Is it to help make the same @executable_path based bundles but support copying in libraries and frameworks that used @rpath and change them over to be @executable_path based? Or is this to help create bundles that result in the use of @rpath? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack Generator for the Mac App Store
On Monday, April 22, 2013 08:22:50 AM Brian Milco wrote: > > Does this workflow in your MacAppStore generator include anything that > > prevents making a .pkg for OS X Installer? > > From the stackoverlfow link below, the person says App Store submissions > > follow different rules. Do you know what those differences are? > > As I've never created an OS X Installer I really don't know. > > > it would be nice to at least start off well and go in the right > > > > direction. > > Agreed. > > > I'm not convinced that an implementation based on the Bundle generator way > > is the right start. > > I started with the Bundle generator because that's what I have been using > to distribute my application for the last couple of years. > > > Maybe I wasn't clear before. CMake can already do .app creation. > > I had forgotten that. I had gone with the Bundle generator two years ago > because I was able to get it working how I wanted quickly and easily. I > based my new generator on it because with the exception of the final dmg vs > pkg packaging they should build the same .app folder structure, and I > wanted both distribution methods to share the package creation and code > signing code. > > I spend some time this weekend looking at the implementation of the new > generator, right now the code signing is in the DragNDrop generator which > makes it available for all derived classes, allowing it to be used for both > Mac App Store signing, and also for developer code signing required by the > default behavior of OS X 10.8 Gatekeeper for non-App Store applications. > > I would like to hear your thoughts on what you think is the best approach > to structuring the code. > > Thanks, > Brian And I'm intrested in other people's thoughts too. I'm starting to think the code signing can be done with a cmake module instead of in the C++ cpack code. Being in DragNDrop generator does not make it available to all cpack generators usable on Mac. The signing of the pkg would still have to be in cpack. As a cmake module, it could be used at packaging time by having a install(CODE ...) in the CMakeLists.txt file. It is my understanding that cmake modules are generally preferred over c++ code, where possible. So my suggestion now is to have code signing in a cmake module, and the new cpack generator be a class derived from cmCPackGenerator. Without the Bundle generator behavior, because people should be able to use any cpack generator without modifying the CMakeLists.txt when switching generators. So, that's my 2 cents. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack Generator for the Mac App Store
Bringing this thread back to the cmake list... - Original Message - > Hi Clint, > On Fri, Apr 12, 2013 at 9:28 AM, Clinton Stimpson < clin...@elemtech.com > > wrote: > > Ok, I now see what is special about it. > > > It uses "productbuild" to generates a .pkg (which is then put inside a > > .dmg), > > The pkg file is not put inside a dmg image, it's uploaded to the App Store > via a piece of software called "Application Loader". > Basically you have a MySoftware.app Bundle inside a .pkg file. Oh. So no .dmg. That is interesting -- oh wait, its creating a "flat" .pkg file, right? The PackageMaker generator also creates .pkg files, but they are not flat. They are directories that can be navigated into much like a .app. The man page for productbuild says it also makes a product archive for the OS X Installer. Last time I looked at PackageMaker a few months back (while trying to fix postflight script support in component mode), I wondered about modifying it to use productbuild internally after realizing that the packagemaker tool was deprecated. But after having this discussion, I realize its good to have a new generator instead of modifying the PackageMaker generator. > I'll admit my understanding of the App Store is somewhat limited, I've > learned what I need in order to submit my application. So I'm sure there are > gaps in my knowledge. > > I haven't been keeping up with all the > > > Mac updates (nor am I really a Mac developer), but isn't productbuild the > > new > > > replacement for PackageMaker? > > I've never used PackageMaker, but a quick google makes it look like > productbuild is the successor. > > How about calling it a ProductBuild generator? Or is it really specific to > > the > > > app store? > > This work flow appears to be specific to the app store. Does this workflow in your MacAppStore generator include anything that prevents making a .pkg for OS X Installer? >From the stackoverlfow link below, the person says App Store submissions >follow different rules. Do you know what those differences are? > My quick google from earlier seemed to indicate that there can be a much more > complex process using additional tools if you're creating a component > installer.[1] While I'd be fine calling this generator ProductBuild I'm not > sure that would actually be an accurate name. If someone who has more > complex packaging requirements was willing to work with me, I would be > willing to make time to add support for additional options and features. Even if there isn't much help, it would be nice to at least start off well and go in the right direction. I'm not convinced that an implementation based on the Bundle generator way is the right start. > > So, it appears to be a replacement for PackageMaker, so I would suggest > > that > > > you not inherit the Bundle generator behavior. > > Given that, for the app store, I need the .app Bundle to be created the only > thing I could see working, off the top of my head, would be to move the .app > creation from the Bundle class to the DragNDrop class. Maybe I wasn't clear before. CMake can already do .app creation. I don't want to see it moved into the DragNDrop generator. See the list of target properties: http://www.cmake.org/cmake/help/v2.8.10/cmake.html#section_PropertiesonTargets There is MACOSX_BUNDLE, MACOSX_BUNDLE_INFO_PLIST for example. Why do we need to create a .app with CPack? If a CPack generator does it, you automatically have a generator limited to certain use cases, which excludes cases such as command line tools, multiple .apps, directory structures, postflight scripts, etc... > [1] > http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re Clint -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack Generator for the Mac App Store
On Thursday, April 11, 2013 03:30:39 PM Brian Milco wrote:
> Hi,
>
> I've added a CPack package generator for the Mac App Store for your
> consideration. You can find it on github:
> https://github.com/iPenguin/cmake/tree/cpack-mac-app-store-generator
>
> This is a first draft, but it should work to get a basic application
> uploaded via Apple's "Application Loader". I have no idea if this will work
> for the iOS App Store. Suggestions and comments are appreciated.
>
> This patch also includes code signing which is required by the Mac App
> Store, but it should also correctly sign your Bundle or DragNDrop packages
> to get your application working with OS X 10.8's default Gatekeeper
> settings if you supply a developer certificate.
>
> If you're building your app for distribution via the Mac App Store, and
> your website or other channels you might want to add something like the
> following to your CMakeLists.txt:
>
> if(${APP_STORE})
> set(CPACK_GENERATOR "MacAppStore")
>
> #The names of the App Store certs you got from Apple iTunesConnect
> set(CPACK_APPLE_CERT_APP "3rd Party Mac Developer Application:
> [YOUR NAME]")
> set(CPACK_APPLE_CERT_INSTALLER "3rd Party Mac Developer Installer:
> [YOUR NAME]")
>
> #The plist file containing your sandboxing entitlements[1]
> set(CPACK_APPLE_ENTITLEMENTS
> "${CMAKE_SOURCE_DIR}/resources/Entitlements.plist")
>
> else()
> set(CPACK_GENERATOR "Bundle")
>
> #The names of the Developer certs you got from Apple iTunesConnect
> set(CPACK_APPLE_CERT_APP "Developer ID Application: [YOUR NAME]")
> set(CPACK_APPLE_CERT_INSTALLER "Developer ID Installer: [YOUR
> NAME]")
> endif()
>
> #A list of additional files that need to be code signed, ie Frameworks,
> plugins, any additional binaries, etc.
> set(CPACK_APPLE_CODESIGN_FILES
> "/Contents/Frameworks/QtCore.framework/Versions/4/QtCore"
>
> "/Contents/Frameworks/QtGui.framework/Versions/4/QtGui")
>
> #how do I reference MACOSX_BUNDLE_GUI_IDENTIFIER directly in the
> generator code?
> set(CPACK_APPLE_BUNDLE_ID "${MACOSX_BUNDLE_GUI_IDENTIFIER}")
>
> -Brian
>
> [1]
> http://developer.apple.com/library/mac/#documentation/Miscellaneous/Referenc
> e/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/u
> id/TP40011195-CH4-SW1
Why do you have this CPack generator creating the .app instead of letting the
CMake build step create the .app from the add_executable( ... MACOSX_BUNDLE ..
)?
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] nested replacement with @@
Another workaround is to make an intermediate variable in the CMakeLists.txt
file and use this intermediate variable from the .in file. That elminates the
nested @@'s.
Clint
On Wednesday, April 10, 2013 07:51:03 PM Eric Clark wrote:
> Nico,
>
> I had this same problem at one point in time, but was able to change it to
> the ${...} syntax which works beautifully. I know that you cannot use this
> syntax, but I will tell you that I did find a work-around for the nested
> @...@ syntax. The workaround is to run configure_file on the file twice.
> The nested @...@ symbols will always be replaced from the inside out which
> is the behavior that you want, you just have to run configure_file on the
> file for as many nests that you have. If the deepest nest you have is two
> nests, then you only need to run configure_file twice. I know this is kind
> of a kludge to fix it, but it does work from my experience...
>
> Hope this helps...
> Eric
>
> > -Original Message-
> > From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
> > Behalf Of Nico Schlömer
> > Sent: Wednesday, April 10, 2013 12:55 PM
> > To: cmake
> > Subject: [CMake] nested replacement with @@
> >
> > Hi all,
> >
> > in a ProjectContfigTemplate.cmake.in file, I'd like to have variables such
> > as ${${PROJECT_NAME}_VERSION}. In ${}-syntax, the nesting is recognized
> > properly, and this string would be replaced by, e.g., "2.1".
> >
> > I know need to have ${}-variables in the output file, so I tried to switch
> > to the @-syntax. Replacing the above line by
> >
> > @@PROJECT_NAME@_VERSION@
> >
> > doesn't work however: The output file contains
> >
> > @Myproject_VERSION@
> >
> > i.e., only the inner variable was replaced.
> >
> > How to fix this?
> >
> > Cheers,
> > Nico
> > --
> >
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] INSTALL_INTERFACE question
I'm playing with some of the new cmake 2.8.11 features and an example I saw had
this:
set_property(TARGET foo PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
"$"
"$"
)
I can see it put the expanded version of "${CMAKE_INSTALL_PREFIX}/include" in
my export file, but I want it to be relocatable. For example, if I use the
CPack ZIP generator, the files can be unzipped anywhere.
If I replace it with "$" , it complains about it
being a relative path.
Why is a relative path disallowed for INSTALL_INTERFACE? Should that be
figured out for me? Maybe it could put ${_IMPORT_PREFIX} in for me if it was a
relative path.
Clint
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest / CDash integration
On Tuesday, April 09, 2013 04:42:57 PM Martin Baute wrote: > Am 09.04.2013 16:29, schrieb Clinton Stimpson: > > How are the config settings and binary path for CTest already given > > in the > > CMakeLists.txt file? Normally, a CMakeLists.txt file does not have a > > hardcoded binary path, nor does it have fixed config settings. > > Wrong wording, sorry. They are, after successful configuration, in the > CMakeCache.txt. Now I'm facing two options regarding CTest: > > - Doing incremental builds only, omitting information e.g. on the > number >of compiler warnings from the data sent to CDash. > > - Wiping the binary directory clean - including the platform-specific >configuration. > > Now, I could set up a CTest script that does the CMake configuration > for me. As it's platform specific, it would have to have lots of if / > else constructs, duplicating most of what CMakeLists.txt does. OR I > could create a CTestScript.cmake.in and forward the necessary settings > from CMakeLists.txt (using configure_file()). > > All this strikes me as somehow needlessly complicated when lots of the > necessary settings *could* be handled by the code that I add when I say > "include( CTest )". Add to that the somewhat lackluster documentation > of CTest itself (no variable docs, several command-line options under- > documented etc.), and I get the feeling that I'm simply *missing* > something, like, a crucial page in the Wiki or an integration guide > or somesuch. From what I've seen from the CMake / CTest / CDash trinity > so far, it's really big on "out of the box" functionality, which is why > I find this issue so confusing. > > Regards, Perhaps it would help if I explained these 2 different ways of using CTest. 1. non scripted mode $ cmake /path/to/source $ ctest -D Experimental This goes through the start/configure/build/test/submit phases using information from the CMakeLists.txt and CMakeCache.txt files. In other words, CMake information is given to CTest. 2. scripted mode $ ctest -S myscript.cmake where myscript.cmake could simply go through the start/configure/build/test/submit phases, or it can do more complex things. You'll also notice that I did not run cmake manually to set up the build tree. That is driven by myscript.cmake. That is the reason the config settings and the binary path go in myscript.cmake, because it is driving. In other words, CTest information is given to CMake. When used this way, I would not try to reverse that and feed CMake information into CTest. Apart from #1 and #2... the include(CTest) and add_test() commands in the CMakeLists.txt files only generate information files for use by CTest in scenario #1 or #2. It is to bridge the CTest and CMake tools (which can be used independently). -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest / CDash integration
On Tuesday, April 09, 2013 04:11:06 PM Martin Baute wrote: > I realize I haven't been all that clear about my intentions. > > I want to keep the amount of configuration files at a minimum. > Lots of the information that is required for CTest (like config > settings, source path, binary path etc.) or CDash (server address, > project name) are already given in CMakeLists.txt, so naturally > I am looking to keep it all together instead of spreading it over > a number of different files cluttering my project. The CDash settings go into the CTestConfig.cmake file and that file resides next to the CMakeLists.txt file. Its in a separate file because one can use CTest/CDash without using CMake. How are the config settings and binary path for CTest already given in the CMakeLists.txt file? Normally, a CMakeLists.txt file does not have a hardcoded binary path, nor does it have fixed config settings. Between different computers, I can set a different binary path, and set different config settings. Because those aren't known in the CMakeLists.txt file, and they can vary between machines, a machine specific CTest script can provide that information. I keep a separate repository for CTest scripts for use by various machines. Each machine uses one of the scripts and can get updates to that script before getting updates to the source it is going to work on. I also keep the bulk of the CTest script in shared files, and the machine specific scripts have minimal code before including a shared script. > > The information available in the documentation is focussing on > various details, but doesn't really explain the "right" (intended) > way of putting together a CMake-built project that supports > uploading CTest results to a CDash server, so I was wondering > if I was missing something. > > Regards, -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] rpmbuild architecture
I'm trying to build an i686 RPM package on a x86_64 Linux machine. I have a set(CPACK_RPM_PACKAGE_ARCHITECTURE i686) but I get an error at CPack time: error: No compatible architectures found for build I can get it to work if I also use setarch when calling rpmbuild giving it the CPack generated RPM spec file, like so: setarch i686 rpmbuild --bb --define "_topdir $PWD" --buildroot $PWD/ SPECS/myspec.spec Doing the equivalent for a Debian package seemed to work by simply setting set(CPACK_DEBIAN_PACKAGE_ARCHITECTURE i386) Is there some way to make this work automatically within cpack? Thanks, Clint -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest & git submodules
Thanks. I may have to do that for now.
However, it seems to me that ctest already does a
git submodule update --recurse
but its missing the --init flag to deal with changes to the .gitmodules file.
Clint
On Tuesday, February 26, 2013 08:26:21 PM NoRulez wrote:
> Here is a working example:
>
> ## -- Update git submodules
> if (EXISTS "${CTEST_SOURCE_DIRECTORY}/.gitmodules")
> message (" -- Update git submodules ${MODEL} - ${CTEST_BUILD_NAME} --")
> execute_process (COMMAND ${GIT_EXECUTABLE} submodule update --init
> --recursive WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
> endif ()
>
> Best Regards
>
> Am 26.02.2013 um 20:16 schrieb NoRulez :
> > Hi,
> >
> > I don't think so, you could check for a .git directory and then call
> >
> > git submodule update --init --recursive
> >
> > Best Regards
> >
> > Am 26.02.2013 um 18:34 schrieb Clinton Stimpson :
> >> Is there anything special I need to do with ctest so that the
> >> ctest_update() will recognize git submodules and do any init/update of
> >> those for me? I assumed it would be automatic, but that doesn't seem to
> >> be the case.>
> > --
> >
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] ctest & git submodules
Is there anything special I need to do with ctest so that the ctest_update() will recognize git submodules and do any init/update of those for me? I assumed it would be automatic, but that doesn't seem to be the case. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding dylib with either @rpath or absolute paths to osx cmd line executable target
If you compile libiomp5 yourself with CMake, you can set the INSTALL_NAME_DIR target property and have CMake put that @rpath in for you instead of a post build rule running install_name_tool. Clint On Tuesday, February 19, 2013 09:03:57 AM Bart Nabbe wrote: > That is precisely what I ended up doing. A per target post build rule that > runs install_name_tool. With all cmake's wizardry, I sorta figured somebody > must have thought about this already ;) > > Thanks for the tip, I feel better now that I did not overlook something! > > On Feb 19, 2013, at 8:58, Clinton Stimpson wrote: > > Have you looked at using "install_name_tool -id" to change the id of the > > shared library. > > > > If you do install_name_tool -id @rpath/libiomp5.dylib > > /path/to/libiomp5.dylib > > > > Then when you link dylibLinkTest and then check it with otool -L, it will > > already have "@rpath/libiomp5.dylib" instead of just a plain > > "libiomp5.dylib" With that, there will be no need to constantly fix your > > executables with install_name_tool each time you link. > > > > BundleUtilities pulls all the dependencies into a bundle and uses > > @executable_path. BundleUtilities does not support @rpath, except that it > > is recognized and changed to @executable_path. > > > > Clint > > > > On Friday, February 15, 2013 06:57:35 PM Bart Nabbe wrote: > >> Hi, > >> > >> I'm sure I just overlooked something, but I can not get shared libraries > >> (at a non system location) to load properly at runtime after having had > >> them linked properly. If I run otool -L the library is listed without > >> any path>> > >> or loader reference: dylibLinkTest: > >>libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0) > >>libtbb.dylib (compatibility version 0.0.0, current version 0.0.0) > >>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > >> > >> 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current > >> version 52.0.0) > >> > >> > >> I can use the install_name_tool to change these to @rpath/libiomp5.dylib > >> and @rpath/libtbb.dylib respectively and all is well (I set rpath with a > >> linker option in my CMakeLists.txt). From searching I did learn about > >> the BundleUtilities, but I'm not quite sure how I would use it or if it > >> would really be suitable to solve the problem. > >> > >> Any suggestions would be greatly appreciated. > >> > >> > >> Thanks, > >> > >> Bart > >> > >> -- > >> > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Please keep messages on-topic and check the CMake FAQ at: > >> http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Follow this link to subscribe/unsubscribe: > >> http://www.cmake.org/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding dylib with either @rpath or absolute paths to osx cmd line executable target
Have you looked at using "install_name_tool -id" to change the id of the shared library. If you do install_name_tool -id @rpath/libiomp5.dylib /path/to/libiomp5.dylib Then when you link dylibLinkTest and then check it with otool -L, it will already have "@rpath/libiomp5.dylib" instead of just a plain "libiomp5.dylib" With that, there will be no need to constantly fix your executables with install_name_tool each time you link. BundleUtilities pulls all the dependencies into a bundle and uses @executable_path. BundleUtilities does not support @rpath, except that it is recognized and changed to @executable_path. Clint On Friday, February 15, 2013 06:57:35 PM Bart Nabbe wrote: > Hi, > > I'm sure I just overlooked something, but I can not get shared libraries (at > a non system location) to load properly at runtime after having had them > linked properly. If I run otool -L the library is listed without any path > or loader reference: dylibLinkTest: > libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0) > libtbb.dylib (compatibility version 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current > version 52.0.0) > > > I can use the install_name_tool to change these to @rpath/libiomp5.dylib and > @rpath/libtbb.dylib respectively and all is well (I set rpath with a linker > option in my CMakeLists.txt). From searching I did learn about the > BundleUtilities, but I'm not quite sure how I would use it or if it would > really be suitable to solve the problem. > > Any suggestions would be greatly appreciated. > > > Thanks, > > Bart > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to compile as 32bit on a 64bit Linux host ?
Or simply specify -m32 at the first configure CFLAGS=-m32 CXXFLAGS=-m32 cmake ../src find_library() works correctly if you do that, and it automatically detects if the 32 bit libraries are in /usr/lib32 or /usr/lib. Clint - Original Message - > Hello, > > On 15/02/13 15:41, Martin Koller wrote: > > I'm just not sure if it is enough to change the compiler flags or if > > there is more to change (paths etc.) > This is why I prefer toolchain files over adding an option inside the > CMakeLists.txt files. On some systems you probably also want to change > the search path for libraries in particular (often /usr/lib32 instead of > /usr/lib), so that the find_package() commands and similar does not find > the incompatible 64 bit libraries. > > In our system we both have an option to "force 32 bit" (which basically > just adds -m32 to compile flags), and I have a toolchain file (which > corresponds to my stackoverflow answer). I find the toolchain file to be > more accurate/flexible to get correct setup. > > In addition to the three lines you might also want to set paths (I do > not need that on my system for my projects), something along the lines of: > > set(CMAKE_FIND_ROOT_PATH /usr/lib32) > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > > Cheers, > Yngve > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
