[CMake] Mac @loader_path for @rpath questions

Tue Jun 17 23:46:57 EDT 2014

Hi Folks,

I have a version of Fixup bundle that support @rpath. See [1]

Test need to be added before it can integrated. It is currently used to
package 3DSlicer on a daily basis. See [2] and [3]. To have a look at the
package, Slicer can be downloaded on http://download.slicer.org

Note that it would need to be rebased against current master and some test
should be added before it could be integrated into CMake master.

And on a different but related topic ...

We also have a hacked version of that same module to allow us to fixup
plugin independently of the main application. See [4]. This basically
allows us to first build the application and then build extension (or
plugin) on demand and fixe-up + package the associated libraries so that
they can be extracted in the application tree and work out of the box.
Since the main .app can be extracted in arbitrary location .. that is the
solution we came up with. If there is some interest, I could elaborate on
this.

Hth
Jc

[1] https://github.com/jcfr/CMake/tree/tweak-bundleutilities-for-rpath

[2]
https://github.com/Slicer/Slicer/blob/master/CMake/BundleUtilitiesWithRPath.cmake

[3]
https://github.com/Slicer/Slicer/blob/master/CMake/SlicerCPackBundleFixup.cmake.in

[4]
https://github.com/Slicer/Slicer/blob/master/CMake/SlicerExtensionCPackBundleFixup.cmake.in

On Wed, Jun 11, 2014 at 9:25 AM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

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

-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140617/56c0ca68/attachment-0001.html>