[CMake] Mac @loader_path for @rpath questions

[Michael Jackson]

On Jun 11, 2014, at 9:08 AM, Eric Wing <ewmailing at gmail.com> wrote:

> On 5/24/14, clinton at elemtech.com <clinton at elemtech.com> wrote:
>> 
>> 
>> ----- 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.
> 
> Okay, the ordering was one thing I screwed up. That was a major reason
> it didn't work for me.
> 
> 
> 
>> 
>> 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?
> 
> That was my ordering screw up. It's working now.
> 
> 
>> 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.
> 
> So 3rd party libraries should be bundled in the .app. This avoids that
> problem. Notice that a real/native Xcode project always does this copy
> phase. I have this working for my stuff now with CMake using some
> aggressive code I wrote. (Similar to the Visual Studio thread I was
> in.)
> 
> 
>> With a list.
>> set_target_properties(bar PROPERTIES INSTALL_RPATH
>> "@loader_path/../Frameworks;@loader_path/../lib")
> 
> Didn't think of that. Thanks that worked.
> 
> 
>>> 
>>> 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.
> 
> Incidentally, I found BundleUtilities/fix_up_bundle, but it seems to
> break if you use @rpath. It doesn't seem to do build time, but install
> time, which is another problem for me.

I use a combination of a "configured" shell script which then calls a "configured" CMake script that itself calls the BundleUtilities during installation and packaging so that I get a complete and proper stand-alone app bundle.

For compile time I ensure that all my 3rd party libraries are compiled with their complete "install_Path" embedded in the libraries themselves so launching and debugging/running isn't a problem as the executable knows where to find the libraries. For our project all of our 3rd party libraries an be compiled by us so we have the luxury of making sure that everything is setup correctly for our OS X developers. If you can NOT change the install_Path in the 3rd party library because the developers do not use -headerpad_max_install_name (**cough Threading Building Blocks ** Cough cough) then you have to end up either copying the library through a cmake copy command or setting the DYLD_LIBRARY_PATH environment variable to get everything to work.

https://github.com/dream3d/DREAM3D/tree/m_develop/Support/cmp/OSX_Tools   has the template files that get configured. 

Thanks
Mike Jackson


> 
> 
> Thanks,
> Eric
>