[CMake] CPack, fixup_bundle, macdeployqt, and QTBUG-5952
KC Jones
kc.jones at skype.net
Wed Jan 5 21:28:26 EST 2011
Me again, with another issue:
On Mac, I'm running into the problem described in QTBUG-5952: http://bugreports.qt.nokia.com/browse/QTBUG-5952 where my CPack generated D&D installer yields an installed app fails with a log message like "Qt internal error: qt_menu.nib could not be loaded." This was also mentioned on this list in http://www.cmake.org/pipermail/cmake/2010-April/036438.html
The resolution in that thread was to copy qt_menu.nib into my bundle's resource directory. Like the original developer on that prior thread, this feels wrong. (And I can't yet make it work.)
I have noticed that if I manually run Qt's macdeployqt script on the app bundle built by my cmake target, there is no problem. It does not copy the qt_menu.nib directory into ./Content/Resources - macdeployqt ends with the menu resources copied into ./Frameworks/QtGui.framework/Resources/qt_menu.nib
In other words, Qt's script which is sort of an equivalent to fixup_bundle in the sense that it rebases all the dynamic libraries, does something to resolve the references to the qt_menu.nib resources that fixup_bundle does not. I have not reverse engineered the script to see what that is, but it generates a working bundle were fixup_bundle falls a bit short.
So I'm not sure what to do at this point. Should I continue trying to copy qt_menu.nib into the bundle manually? Should I attempt to run the macdeployqt script on the bundle instead of calling fixup_bundle??
This does seem like a bug in Qt4.7 - but it has also remained unfixed in Qt4.7.1, and macdeployqt does something magical, so holding my breath and waiting for a fix is not an option. Ideas and suggestions welcome.
KC Jones
kc.jones at skype.net
SkypeId: bernalkc
More information about the CMake
mailing list