[CMake] BundleUtilities Error between 2.8.3 and 2.8.4

Michael Jackson mike.jackson at bluequartz.net
Thu Mar 31 12:39:43 EDT 2011


http://public.kitware.com/Bug/view.php?id=12034

I'll wait for 2.8.5 before my next upgrade rather than spend time introducing hacks/workarounds then have to undo everything when the bug is fixed.
___________________________________________________________
Mike Jackson                      www.bluequartz.net
Principal Software Engineer       mike.jackson at bluequartz.net 
BlueQuartz Software               Dayton, Ohio

On Mar 31, 2011, at 12:01 PM, David Cole wrote:

> On Thu, Mar 31, 2011 at 8:29 AM, Michael Jackson <mike.jackson at bluequartz.net> wrote:
> So things did majorly change between the two versions. My questions are now 1) How do I "fixup" an executable that is NOT an application bundle and 2) Do I now need to supply my own copy rules for things like Qt Frameworks, 3rd party, but non-system libraries?
> 
> 1) Now that we're strictly producing an error out when a file is not "inside" the bundle, fixing up a plain command line executable that is not inside a bundle structure on the Mac has been made "ill defined" (inadvertently...)
> 
> We do not have a test in the CMake test suite of calling fixup_bundle on such a creature. If we did, I would have caught this immediately when making that change.
> 
> As a possible workaround (not 100% certain it will work, but I think it should), "pretend" your app is in a bundle simply by naming its containing directory with a name ending in ".app". You could even fake it out by renaming the directory to have the ".app", calling fixup_bundle, and then renaming the dir back to its original name. This is a workaround (*cough* hack *cough*), and only suggested so you can use it immediately if it works for you...
> 
> In the meantime, this should be fixed to deal with this case on the Mac, since it does essentially the same thing on Windows and Linux, where there is no convention of a "bundle structure"...
> 
> We need a new test added that is shown to fail presently, and then a fix to make it pass, while still maintaining all our other existing fixup_bundle behavior.
> 
> 2) You need to supply install rules for "dynamically loaded shared libraries" (like plugins) -- fixup_bundle will only copy in files that it determines are necessary based on otool -L output. It no longer copies in the "${libs}" list as it used to in CMake 2.8.3 and earlier.
> 
> (Which is why we added the error message to 2.8.4 -- to explicitly call attention to the fact that we inadvertently changed the behavior with one of the bug fixes we allowed in the 2.8.3 release...)
> 



More information about the CMake mailing list