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.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
