[cmake-developers] [CMake 0012034]: BundleUtilities can not fixup standalone executable on OS X

Mantis Bug Tracker mantis at public.kitware.com
Thu Mar 31 12:38:37 EDT 2011


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=12034 
====================================================================== 
Reported By:                Mike Jackson
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   12034
Category:                   CMake
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2011-03-31 12:38 EDT
Last Modified:              2011-03-31 12:38 EDT
====================================================================== 
Summary:                    BundleUtilities can not fixup standalone executable
on OS X
Description: 
Using the BundleUtilities on OS X and trying to fixup a plain executable will
fail because the executable is expected to be included in a .app package

Additional Information: 
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?

> David Cole Replied
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...)

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-31 12:38 Mike Jackson   New Issue                                    
======================================================================




More information about the cmake-developers mailing list