[CMake] BundleUtilities

[Michael Jackson]

On Nov 17, 2010, at 12:20 PM, Clinton Stimpson wrote:

> 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 having problems with the BundleUtilities.cmake doing what I  
needed it to do so I wrote the code I quoted a while ago and have just  
used it ever since because it works for _my_ projects. I'll eventually  
take a look at how the BundleUtilities works in CMake 2.8.3 and see  
what code I can get rid of.

And just for completeness the macro that I pointed is called from  
another macro that sets up the OS X plist entry, icon file and some  
other stuff, generates all the extra shell scripts and cmake files so  
at the top level you have:

IF(APPLE)
  SET(GUI_TYPE MACOSX_BUNDLE)
  ConfigureMacOSXBundlePlist(IPHelperApp ${EXE_DEBUG_EXTENSION}
                             ${PROJECT_RESOURCES_DIR}/icons/icns/ 
IPHelperApp.icns
                             ${IPHelper_VERSION} )
ENDIF (APPLE)

cmp_InstallationSupport(IPHelperApp ${EXE_DEBUG_EXTENSION} $ 
{IPHelperApp_BINARY_DIR} "1")

--
Mike Jackson <www.bluequartz.net>