On Wed, Nov 17, 2010 at 11:46 AM, David Doria <<a href="mailto:daviddoria@gmail.com">daviddoria@gmail.com</a>> wrote:<br>> On Wed, Nov 17, 2010 at 9:32 AM, Michael Jackson<br>> <<a href="mailto:mike.jackson@bluequartz.net">mike.jackson@bluequartz.net</a>> wrote:<br>
>> I tool a little different approach in my own projects. I end up<br>>> "configuring" a shell script that gets run at install time (OS X Only).<br>>> Inside that shell script are all the copying to the CMAKE_INSTALL_PREFIX,<br>
>> ensuring destination directories inside the OS X App bundle are setup<br>>> (Plugins, libs, Frameworks) and then finally calling the BundleUtilities to<br>>> copy all the dependent libraries and plugins into the App bundle and<br>
>> "fixing" the install_name embedded in each library so that they point to<br>>> libraries inside the bundle. For Qt projects I also make sure a blank<br>>> qt.conf file and qtmenu.nib file are properly copied into the bundle.<br>
>><br>>> There are some "dark" issues when it comes to plugins. The basic<br>>> BundleUtilities will look for files that end with .dylib (on OS X) and copy<br>>> those to the "lib" directory and frameworks into the Framework directory.<br>
>> The issue for me was when I had plugins with .dylib file extensions these<br>>> would always be copied into the wrong directory. I had to make sure I used a<br>>> set properties to set the file extension of my own plugins to .plugin so I<br>
>> had a guaranteed way to tell the difference between a support library that<br>>> should go into "lib" and a plugin that should get copied into Plugins. One<br>>> form of this can be found at<br>
>> <<a href="http://scm.bluequartz.net/support-libraries/cmp/blobs/master/OSX_Tools/CompleteBundle.cmake.in">http://scm.bluequartz.net/support-libraries/cmp/blobs/master/OSX_Tools/CompleteBundle.cmake.in</a>><br>
>> There may be some Qt specific lines in the file and it is OS X specific.<br>>> Also note that you can over-ride some of the BundleUtilities commands in<br>>> order to implement variations that suit your own needs.<br>
>><br>>> ___________________________________________________________<br>>> Mike Jackson <a href="http://www.bluequartz.net">www.bluequartz.net</a><br>><br>> David C. -<br>><br>
> Is what Mike is doing here a work around or is this how<br>> BundleUtilities is intended to be used?<br>><br>> I was *hoping* for something more along the lines of simply:<br>><br>> INSTALL(Qt)<br>> INSTALL(VTK)<br>
><br>> Those two lines would include everything necessary from Qt and VTK in<br>> your project so you can hand someone without those tools your code and<br>> it will run.<br>><br>> Is this the goal and it is just not that easy (yet)? Or I am missing something?<br>
><br>> David D.<br>><br><br><br>The goal is simply this:<br><br>- given:<br> -- an executable target, that happens to be a bundle app on the Mac<br> -- a full path to that bundle in the install tree<br> -- a list of plugins that you have also already installed in the bundle<br>
-- a list of directories where to find libraries that your executables and plugins depend on<br><br>that the following CMake code:<br><br>install(CODE "<br> include(BundleUtilities)<br> fixup_bundle(\"${YOUR_BUNDLE_PATH}\" \"\${YOUR_PLUGINS}\" \"${YOUR_LIBRARY_DIRS}\")<br>
" COMPONENT Runtime)<br><br>will do all the analysis and copying and fixing up of dependent libraries that is mechanically possible...<br><br>So that you do not even have to mention VTK and Qt to your install rules at all.<br>
<br>If you have to say anything about VTK or Qt beyond target_link_libraries, then BundleUtilities is a failure.<br><br><br>David C.<br><br>