[CMake] CMake 2.8.0 built on OS X crashes on Startup.

[Michael Wild]

That's what I meant ;-)

On 5. Dec, 2009, at 15:25 , Mike Jackson wrote:

> Qt 4.5 Carbon does not require the qt_menu.nib to be in the final
> shipping application which is why all the previous scripts work. But
> then again, you probably knew that... ;-)
> _________________________________________________________
> Mike Jackson                  mike.jackson at bluequartz.net
>
> On Sat, Dec 5, 2009 at 9:11 AM, Michael Wild <themiwi at gmail.com>  
> wrote:
>>
>> On 5. Dec, 2009, at 14:47 , Mike Jackson wrote:
>>
>>> Probably what is going to happen is there will be "special" case
>>> copies from frameworks into bundles. In this case, copying the
>>> qt_menu.nib and any qt.conf is probably specific to QtGui.framework.
>>> At this point I there is probably 2 things that need to happen.
>>>
>>> A bug report for the QtGui resources not being copied into  
>>> ParaView and
>>> CMake
>>> A feature request to enhance the copying of Frameworks to
>>> include/exclude any of the directories within a framework.
>>>
>>
>> Agreed
>>
>>> The first one should be quick to solve for someone on the
>>> ParaView/Cmake teams since it is the same code.
>>>
>>>  The second one may be tougher because besides the couple of "well
>>> known" directories inside frameworks, a developer can pretty much  
>>> put
>>> anything inside a framework. I'll leave it up to the CMake  
>>> developers
>>> to come up with something if anything is really deemed needed.
>>>
>>
>> It would be nice to have a function allowing one to override/extend  
>> the
>> default choice (which AFAIK is determined by asking otool about
>> link-dependencies). Perhaps something like this:
>>
>> set_external_framework_properties(
>>  ${QT_QTGUI_LIBRARY} PROPERTIES
>>  REQUIRE Resources/qt_menu.nib DESTINATION <APP_BUNDLE>/Resources
>>  REQUIRE Versions/Current/Headers DESTINATION <FRAMEWORK>
>>  )
>>
>> which sets a few directory properties which then are used by
>> fixup_bundle_item from the BundleUtilities for customizing the copied
>> framework. The <APP_BUNDLE> and <FRAMEWORK> strings could resolve  
>> to the
>> application-bundle being fixed up and the framework bundle directory,
>> respectively.
>>
>>> Of course my frustration is really ONLY valid if building CMake
>>> against Qt 4.5 is an Officially sanctioned/supported platform. If Qt
>>> 4.5 is Officially supported then CMake 2.8 is Broken and needs an
>>> update ASAP to bring it up to par. Period. If Qt 4.4 is the ONLY
>>> version sanctioned by CMake then nothing is really broken and the
>>> problem is my own.
>>
>> I think it works fine with Qt 4.5 Carbon, not the Cocoa version.
>>
>>
>> Michael
>>