[CMake] fixup_bundle, shared libs and Plugins

David Cole david.cole at kitware.com
Tue Jan 11 12:22:21 EST 2011 

On Tue, Jan 11, 2011 at 12:08 PM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

> This is wonderful and I am making progress but I have a few more questions.
> Assume I am using CMake 2.8.3 (as it will become the requirement).
>
>  For external Dylibs and frameworks that my project depends on will the new
> way that bundle utilities work still copy the frameworks (like Qt
> frameworks) and external libraries (like HDF5, libTiff .. ) that are NOT
> part of my project? So my project builds its own couple of libraries (AIMLib
> & MXADataModel) but also depends on some external libraries (HDF5, libTiff,
> Expat, Boost). Do I need to have install rules or otherwise get those copied
> into the the bundle BEFORE calling fixup_bundle()?
>

No -- if we did that, BundleUtilities would truly be nearly useless. :-)

If a prerequisite is pulled in via dependency analysis, then fixup_bundle
will still copy it in (assuming it's not classified as a "system" library
("system" == assumed to be pre-installed and available everywhere...))

The change was made only for the "additional libraries" passed in as the
parameter to fixup_bundle, which primarily equates to plugins...

The idea is: you know the additional libraries anyway because you're passing
them in, so you should install them in the bundle beforehand and pass in the
names just for prerequisite analysis and fixup. The additional libraries
will not show up in the prerequisites analysis because they are typically
only loaded dynamically at runtime. Hard links to non-system frameworks and
libraries will be copied in and fixed up.


HTH,
David



>
> At this point I am creating an function much like the ones in ParaView that
> take all the arguments needed to create the App and then applying all of
> these rules, at least for OS X. I have the installation working on Windows
> (so far... )
>
> Thanks
> --
> Mike Jackson <www.bluequartz.net>
>
> On Jan 11, 2011, at 11:17 AM, David Cole wrote:
>
> > 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
> >
>
> _______________________________________________
> 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/f9213577/attachment-0001.htm>

More information about the CMake mailing list