[CMake] fixup_bundle, shared libs and Plugins
David Cole
david.cole at kitware.com
Tue Jan 11 11:17:31 EST 2011
On Tue, Jan 11, 2011 at 10:31 AM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:
> Thanks for the explanation David it really helps to narrow down what might
> be going on. Couple of comments. Starting fresh this morning everything
> seems to be working correctly after simply deleting the build folder and
> starting over. So maybe I had a stale cmake variable floating around.
> Also the part where BundleUtilities is NOT copying the libraries was also
> catching me by surprise as I was probably dependent on that part working in
> previous versions of CMake. The change is fine now that I know to look for
> it.
>
You're welcome. (Glad you're amenable to this and willing to roll with the
change... There were 2 different perspectives about how BundleUtilities were
used before this change and we chose one of them as 'preferred' and are now
enforcing it...)
> Can I have multiple install rules for the same target?
Yes, absolutely. It will get copied (as needed) from build to install
location for each install rule you have for it.
> Reason I ask is that a few of the libraries that get built are used by
> several applications. Also, how exactly do I have an install rule for a
> Library gets installed into an app bundle? I would need to know the complete
> path and complete name of the App bundle which for my projects changes
> depending on Debug or Release builds. I guess I am having a problem wrapping
> my head around this again.
>
Let's say your app is installed by:
install(TARGETS App BUNDLE DESTINATION "My App 1.2.3")
(this should put an "App.app" bundle in a folder "My App 1.2.3" at the root
of the make install tree...)
Then, after that install rule, add one like this for a plugin installed into
the .app bundle:
foreach(pi ${plugins})
install(PROGRAMS ${pi}
DESTINATION "My App 1.2.3/App.app/Contents/plugins"
)
endforeach()
(In this case, plugins must be full path file names, but if your plugins are
targets instead, you could simply use the "install(TARGETS" signature
again... And it's only if they are targets that the Debug/Release confusion
comes into play. If they're not targets, you should be referencing the
libraries by full path name already anyway.)
Of course, in your real code, you'll want to use variables and avoid
duplicating the hard-coded strings used in the example, but you get the
idea.
Let me know if there's a specific issue you're having a problem with.
Thanks,
David
>
> Thanks
> --
> Mike Jackson <www.bluequartz.net>
>
> On Jan 11, 2011, at 10:19 AM, David Cole wrote:
>
> > Do you get different results if you use CMake from git 'master' or 'next'
> ?? (Or CMake 2.8.2...?)
> >
> > In 2.8.3, there was a change introduced that caused problems in *some*
> projects. I suspect your project is one of them.
> >
> > This commit:
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2895f48a4e79af49937b9e6a260076440b1a67a
> > made a fix to BundleUtilities to cause a FATAL_ERROR if one of the fixed
> up libraries is not inside the bundle. (It is assumed that all libraries are
> either: in the bundle to start with, or copied in by fixup_bundle itself.
> >
> > Read the commit comments carefully for all the gory details.
> >
> > Suffice it to say:
> > - there was a bug fix made, and released in 2.8.3 (
> http://public.kitware.com/Bug/view.php?id=10417 )
> > - it is backwards-incompatible for *some* previously successful users of
> fixup_bundle
> > - we will be keeping the change despite this one-time backwards
> incompatibility
> > - the above referenced commit (c2895f48) will help projects that suffer
> from this condition to identify any problem libraries in its
> prerequisites...
> >
> > Hopefully.... (?) you are suffering from this problem, and simply using
> the new BundleUtilities will highlight where you may need additional install
> rules.
> >
> > The bottom line is:
> > We used to copy in the libraries that you passed to us, even though they
> were outside the bundle. Now we expect the libraries that you are passing in
> for fixup are already inside the bundle, and that you should have install
> rules for them to be in there before calling fixup_bundle...
> >
> > Sorry for the inconvenience.
> >
> > Hope this answers it,
> > David
> >
> >
> > On Mon, Jan 10, 2011 at 6:24 PM, Michael Jackson <
> mike.jackson at bluequartz.net> wrote:
> > And just to follow up a bit with something else, I added the following
> bit of cmake code for the 2 libraries MXADataModel and AIMLib:
> >
> > SET_TARGET_PROPERTIES(${targetName}
> > PROPERTIES
> > LINK_FLAGS "-current_version ${${CMP_PROJECT_NAME}_VERSION}
> -compatibility_version ${${CMP_PROJECT_NAME}_VERSION}"
> > INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib"
> > BUILD_WITH_INSTALL_RPATH 1
> > )
> >
> > And now I can get everything to work. This seems like an odd thing to
> have to add. Why can't fixup_bundle() resolve an item that is in the build
> tree? Seems that I have to install the library FIRST to an external location
> with the proper install_name for that location then run my fixup_bundle(). I
> can't see the difference.
> > --
> > Mike Jackson <www.bluequartz.net>
> >
> > On Jan 10, 2011, at 6:12 PM, Michael Jackson wrote:
> >
> > > CMake 2.8.3, OS X 10.6.6, Makefiles
> > >
> > > I am attempting to use fixup_bundle() to create my OS X app bundle. The
> issue I am running into is that under a certain case some common libraries
> that get built by the project are not being resolved correctly. Here goes
> the explanation:
> > >
> > > I have a project "IPHelper.app". Part of the project is building 2
> shared libraries, MXADataModel and AIMLib. I also use some of the Qt
> Imageformat plugins and I build my own Qt Plugins for the application.
> > >
> > > So, I use fixup_bundle (from a .cmake file that gets configured). I
> have a list of the plugins (both mine and Qt's image formats) that gets
> passed in. I also have a list of directories to search for libraries.
> > >
> > > Here is the snippet of CMake code:
> > > fixup_bundle("${CMAKE_INSTALL_PREFIX}/IPHelperApp.app"
> > > # Plugins to Install
> > > "${PLUGIN_LIST}"
> > > # Directories to Search for Libraries
> > >
> "/Users/mjackson/Workspace/IPHelper/Build/Bin;/Users/Shared/Toolkits/Qt-4.6.2-Cocoa/bin;/Users/Shared/Toolkits/Qt-4.6.2-Cocoa/lib;/Users/Shared/Toolkits/Qt-4.6.2-Cocoa/plugins/imageformats")
> > >
> > > If I run "make install" I will get all the plugins but NONE of the
> libraries (MXADataModel and AIMLib) copied or fixed up.
> > >
> > > If I run "make install" where the ${PLUGIN_LIST} variable is actually
> blank then I get the libraries (MXADataModel and AIMLib) to resolve, copy
> and get fixed up, but obviously none of the plugins. I am not sure if I am
> doing something wrong, there is a bug in BundleUtilities or what.
> > >
> > > Some output from the first run where I have a plugin list with some
> status output enabled from BundleUtilities.cmake:
> > >
> > > -- 7/20: copying '@executable_path/../lib/libAIMLib.dylib'
> > > -- key='libAIMLib_dylib'
> > > -- item='@executable_path/../lib/libAIMLib.dylib'
> > > -- resolved_item='@executable_path/../lib/libAIMLib.dylib'
> > > -- default_embedded_path='@executable_path/../lib'
> > > -- embedded_item='@executable_path/../lib/libAIMLib.dylib'
> > > --
> resolved_embedded_item='/Users/Shared/Toolkits/IPHelper/IPHelperApp.app/Contents/lib/libAIMLib.dylib'
> > > -- copyflag='1'
> > > --
> > > Error copying file "@executable_path/../lib/libAIMLib.dylib" to
> "/Users/Shared/Toolkits/IPHelper/IPHelperApp.app/Contents/lib/libAIMLib.dylib".
> > >
> > >
> > > and here is output from the second run:
> > > -- 4/10: copying
> '/Users/mjackson/Workspace/IPHelper/Build/Bin/libAIMLib.dylib'
> > > -- key='libAIMLib_dylib'
> > > -- item='libAIMLib.dylib'
> > > --
> resolved_item='/Users/mjackson/Workspace/IPHelper/Build/Bin/libAIMLib.dylib'
> > > -- default_embedded_path='@executable_path/../lib'
> > > -- embedded_item='@executable_path/../lib/libAIMLib.dylib'
> > > --
> resolved_embedded_item='/Users/Shared/Toolkits/IPHelper/IPHelperApp.app/Contents/lib/libAIMLib.dylib'
> > > -- copyflag='1'
> > >
> > > I have no idea what is going on and would appreciate any enlightening
> thoughts. Maybe I am just not using fixup_bundle correctly.
> > >
> > > The source is located at http://scm.bluequartz.net/eim/iphelper on the
> "user_init" branch.
> > >
> > > Thanks
> > > ___________________________________________________________
> > > Mike Jackson www.bluequartz.net
> > > Principal Software Engineer mike.jackson at bluequartz.net
> > > BlueQuartz Software Dayton, Ohio
> > >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110111/1ef86fda/attachment-0001.htm>
More information about the CMake
mailing list