[cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[Adam Strzelecki]

> Regardless of where the bug lies, your changes took a packaging
> case that worked and made it not work.  That is a regression.

I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed in:

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html

and expected by code-sign.

Resources/ folder needs to lie in VERSION folder, so in out case QtGui.framework/Versions/4/Resources/

Previous CMake was checking and copying QtGui.framework/Resources/ which is WRONG as this is wrong place, and it may just be symlink to CORRECT place. But such symlink is not obligatory in final bundle.

It WAS working because Qt was looking in WRONG place for .nib file that was copied. Also before 10.9.5 it was code signing well because Apple put some heuristics to allow lousy bundles. But these were removed in 10.9.5 for code signed bundles.

But assuming we restore Resources/ optional symlink we can circumvent that. And I am working on the patch, just give me few minutes.

> Working around it for the packaging machine of CMake itself is
> not a solution because it could happen to any project built this
> way.

I used wrong word, this was not workaround, but introduction of correct behavior. But I will add extra change that will restore Resources/ symlinks as well.

> Please extend your changes to restore successful packaging with
> no special help by adding whatever workarounds are needed.

If I remove all workarounds and do it ONLY correct way as Apple specified then apps using currently release Qt SDKs will not work :>

Please note this has been fixes in Qt 5.4 beta, so we could remove workarounds, but then only most recent Qt SDK would work fine.

If you need more information ping me on IRC.

--Adam