[CMake] BundleUtilities (was RPATH on Mac)

[David Cole]

On Wed, Apr 20, 2011 at 11:38 AM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

>
> ___________________________________________________________
> Mike Jackson                      www.bluequartz.net
> Principal Software Engineer       mike.jackson at bluequartz.net
> BlueQuartz Software               Dayton, Ohio
>
> On Apr 20, 2011, at 11:25 AM, David Cole wrote:
>
> > On Wed, Apr 20, 2011 at 11:17 AM, Michael Jackson <
> mike.jackson at bluequartz.net> wrote:
> > On Apr 20, 2011, at 10:55 AM, David Cole wrote:
> >
> > >
> > > What is wrong with that one ?
> > >
> > > Nothing is wrong with it, but there is no link from the app to the
> plugin, so fixup_bundle cannot determine that it's necessary and
> automatically pull it in. The plugin, from the app's point of view, is
> something that may or may not exist, and if it does, it's dynamically
> loaded. So you need to install it into the bundle first, and then you need
> to tell fixup_bundle about it so that it gets included in the set of fixed
> up libraries.
> > >
> > > Hope this helps,
> > > David
> >
> > Is that the part that changed from CMake 2.8.3 to 2.8.4? I am using CMake
> 2.8.3 and all my code works fine but I don't think I explicitly "install"
> the plugin but rather list it (the absolute path to the built plugin) as an
> argument to the "fixup_bundle" function. Will that scheme still work under
> CMake 2.8.4?
> >
> >  There are some other issues with CMake 2.8.4 with BundleUtilities and my
> code which is why I have not updated from 2.8.3
> >
> > Mike Jackson
> > www.bluequartz.net
> >
> >
> >
> > In CMake 2.8.3 and earlier, libs listed in the 2nd arg to fixup_bundle
> were copied into the bundle. Half the people using it considered that
> behavior a bug, half liked it just fine.
> >
> > In 2.8.4, we "fixed" the bug (really, transferred it to the other half of
> the people)...
> >
> > In retrospect, I never should have allowed that change to go into CMake,
> but there you have it: 2.8.3 and earlier copy the plugins, 2.8.4 and later
> do not.
> >
> > So: if you want a plugin inside your bundle, with CMake 2.8.4 and later,
> you have to copy/install the plugin into the bundle yourself before calling
> fixup_bundle.
> >
> >
> > Sorry for the persisting confusion,
> > David
> >
>
> So I should probably put the copy step into my configured cmake file that
> runs the 'fixup_bundle'? I guess an install rule with the proper path inside
> the app bundle should work. Isn't there an easier way? BUNDLE DESTINATION
> argument to the INSTALL(target.. ) should do it also correct?
>
> Thanks
> Mike Jackson
> _______________________________________________
> 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
>

I would recommend something like this (top of my head, not actually building
from this):

  install( TARGETS myapp BUNDLE DESTINATION . )

That should produce a directory structure in CMAKE_INSTALL_PREFIX like so:

  ./myapp.app/Contents/MacOS/myapp

Then for the plugin, something like:

  install( TARGETS plugin DESTINATION myapp.app/Contents/plugins )

Which should yield:

  ./myapp.app/Contents/MacOS/myapp
  ./myapp.app/Contents/plugins/libplugin.dylib

Something along those lines. And then pass the full path to libplugin.dylib
to fixup_bundle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110420/069b439b/attachment.htm>