[CMake] BundleUtilities

[Clinton Stimpson]

On Wednesday, November 17, 2010 09:46:23 am David Doria wrote:
> On Wed, Nov 17, 2010 at 9:32 AM, Michael Jackson
> 
> <mike.jackson at bluequartz.net> wrote:
> > I tool a little different approach in my own projects. I end up
> > "configuring" a shell script that gets run at install time (OS X Only).
> > Inside that shell script are all the copying to the CMAKE_INSTALL_PREFIX,
> > ensuring destination directories inside the OS X App bundle are setup
> > (Plugins, libs, Frameworks) and then finally calling the BundleUtilities
> > to copy all the dependent libraries and plugins into the App bundle and
> > "fixing" the install_name embedded in each library so that they point to
> > libraries inside the bundle. For Qt projects I also make sure a blank
> > qt.conf file and qtmenu.nib file are properly copied into the bundle.
> > 
> >  There are some "dark" issues when it comes to plugins. The basic
> > BundleUtilities will look for files that end with .dylib (on OS X) and
> > copy those to the "lib" directory and frameworks into the Framework
> > directory. The issue for me was when I had plugins with .dylib file
> > extensions these would always be copied into the wrong directory. I had
> > to make sure I used a set properties to set the file extension of my own
> > plugins to .plugin so I had a guaranteed way to tell the difference
> > between a support library that should go into "lib" and a plugin that
> > should get copied into Plugins. One form of this can be found at
> > <http://scm.bluequartz.net/support-libraries/cmp/blobs/master/OSX_Tools/C
> > ompleteBundle.cmake.in> There may be some Qt specific lines in the file
> > and it is OS X specific. Also note that you can over-ride some of the
> > BundleUtilities commands in order to implement variations that suit your
> > own needs.
> > 
> > ___________________________________________________________
> > Mike Jackson                      www.bluequartz.net
> 
> David C. -
> 
> Is what Mike is doing here a work around or is this how
> BundleUtilities is intended to be used?

Looks like a workaround to me.  Its had problems before, but if you use cmake 
2.8.3, you'll be better off.

> 
> I was *hoping* for something more along the lines of simply:
> 
> INSTALL(Qt)
> INSTALL(VTK)
> 
> Those two lines would include everything necessary from Qt and VTK in
> your project so you can hand someone without those tools your code and
> it will run.

The issue with an approach like that is Qt and VTK have multiple ways of being 
configured, with multiple libraries that you may or may not be using in your 
application.  The multiple configurations may or may not depend on extra 
libraries.  Those extra libraries may or may not be part of the system.
And if your own project has configurations that may or may not depend on Qt, 
VTK, etc... then you'll have to keep track of what macros to call.
Maintaining macros like that for each project is too much work.

BundleUtilities is meant to be a more general approach to packaging 3rd party 
libraries.  It will look at an executable, and find all of its dependencies 
(the ones necessary to make the program execute) and copy the non-system 
dependencies into your install directory.

Then there are extra things an application might need to run that 
BundleUtilities can not find from the executable.  These may include plugins 
and resource files.  You have to know what those are and install them.
BundleUtilities can be given the plugins and it'll check them out and possibly 
pull in extra dependencies.  For the resource files, you're currently on your 
own.

For Qt projects, a macro for creating a qt.conf file and a macro for installing 
Qt plugins would be nice to have in FindQt4.cmake (anyone want to take a stab 
at that?)

Clint