[CMake] CMake 2.8.1 + Qt/Cocoa + OS X Problem -- qt_menu.nib not getting copied

[Michael Wild]

On 16. Apr, 2010, at 18:03 , David Cole wrote:

> On Fri, Apr 16, 2010 at 11:22 AM, Michael Jackson <
> mike.jackson at bluequartz.net> wrote:
> 
>> While I agree with everything said I think a Qt Specific function for
>> "deploying Apps", whether those are on Windows, OS X or linux, should be
>> created. The script would be at a higher level than BundleUtilites as I
>> would envision DeployQt4App.cmake calling BundleUtilities, checking the type
>> of Qt being used (Relevant on OS X), copying the plugins (if wanted by the
>> user) and stuff like that. Thoughts?
>> 
> 
> Sounds like a reasonable idea. I would recommend naming it
> "DeployQtApp.cmake" and leave out the 4 in anticipation of an eventual Qt
> 5...
> 
> I would also encourage you to put "stuff generally useful even to non-Qt
> apps" into BundleUtilities and make sure that DeployQtApp is really only
> Qt-specific deployment related stuff.
> 
> BundleUtilities, while it was originally started to handle Mac-specific
> bundling issues, has evolved to be useful on Linux and Windows now too.
> 
> 
> David


While I like both ideas (i.e. having the option to install everything in a framework and the DeployQtApp.cmake), I'd also like to have more fine-grained control, because the option "install only libraries" will never work with Qt-Cocoa, so it is broken in this case. Also, installing everything is a pretty pessimistic approach, most users won't be particularly interested in all the header files.

I know that FindQt4.cmake currently does not create imported targets for the Qt frameworks (claiming that imported targets currently don't work with frameworks), but if this was fixed, one could update it to detect Qt-Cocoa and then set the RESOURCE target property accordingly which could then be used by GetPrerequisites to do the right thing (TM).

Also, this approach has the advantage that it could be used by other FindXXX and XXX-config modules.

Michael