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.jack...@bluequartz.net
On Sat, Dec 5, 2009 at 9:11 AM, Michael Wild <them...@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
>
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
