On Wed, Apr 20, 2011 at 11:38 AM, Michael Jackson < mike.jack...@bluequartz.net> wrote:
> > ___________________________________________________________ > Mike Jackson www.bluequartz.net > Principal Software Engineer mike.jack...@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.jack...@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.
_______________________________________________ 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
