Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/21/2014 11:45 AM, Brad King wrote: I cherry-picked it over on top of the revised/squashed copy of the topic that was merged to 'master': BundleUtilities: Ensure framework symlinks and Info.plist exist http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2 The nightly binary works again. The first working version after this gap is now: http://www.cmake.org/files/dev/cmake-3.1.20141021-gffa1-Darwin64-universal.dmg Thanks! -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
The nightly binary works again. The first working version after this gap is now: Great! Now, do you plan code signing the CMake.app? Do you guys have Mac Developer ID? --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On Wed, 22 Oct 2014 19:29:00 +0200, Adam Strzelecki said: The nightly binary works again. The first working version after this gap is now: Great! Now, do you plan code signing the CMake.app? Do you guys have Mac Developer ID? The bug for that is here BTW, created over 2 years ago now... http://public.kitware.com/Bug/view.php?id=13532 Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/20/2014 06:41 PM, Adam Strzelecki wrote: Did you build against Qt4 SDK taken from official installer? It's a qt 4.8.0 installed from source. configure --prefix=... -opensource -confirm-license \ -nomake demos -nomake examples -cocoa -shared -release \ -arch x86 x86_64 We also tried one with just -arch x86_64 as part of trying to package only that architecture, but it has the same problem. Can you put these both binaries somewhere (zipped) in the cloud? Nightly binaries are always published here: http://www.cmake.org/files/dev/ Specifically: http://www.cmake.org/files/dev/cmake-3.0.20140929-g5748a-Darwin64-universal.dmg http://www.cmake.org/files/dev/cmake-3.0.20140930-g37776-Darwin64-universal.dmg BTW. Any reason to not use Qt5? We already have the infrastructure set up to use Qt4 and it has worked well for years. Prior to your patch the Qt5 package did not work for redistribution due to the plugin problem anyway. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Also as follow up the same Qt build is used for all Darwin64 releases and nightlies. As far as I am aware this Qt build has been producing valid deployable frameworks since before CMake 2.8.8 On Tue, Oct 21, 2014 at 8:28 AM, Brad King brad.k...@kitware.com wrote: On 10/20/2014 06:41 PM, Adam Strzelecki wrote: Did you build against Qt4 SDK taken from official installer? It's a qt 4.8.0 installed from source. configure --prefix=... -opensource -confirm-license \ -nomake demos -nomake examples -cocoa -shared -release \ -arch x86 x86_64 We also tried one with just -arch x86_64 as part of trying to package only that architecture, but it has the same problem. Can you put these both binaries somewhere (zipped) in the cloud? Nightly binaries are always published here: http://www.cmake.org/files/dev/ Specifically: http://www.cmake.org/files/dev/cmake-3.0.20140929-g5748a-Darwin64-universal.dmg http://www.cmake.org/files/dev/cmake-3.0.20140930-g37776-Darwin64-universal.dmg BTW. Any reason to not use Qt5? We already have the infrastructure set up to use Qt4 and it has worked well for years. Prior to your patch the Qt5 package did not work for redistribution due to the plugin problem anyway. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Please hold your breath, and don't yet revert my patches because you will end up with bundle that you cannot code-sign anyway for 10.10 and =10.9.5 and it will be bad release that will be rejected by Gatekeeper upon launch. First of all this is in fact Qt bug, please follow discussion at: http://lists.qt-project.org/pipermail/development/2014-September/018505.html The patches I provided, especially 55707fd5, were intended to workaround that so app will code-sign with =10.9.5, especially for Qt case where their frameworks had incorrect layout causing code sign fail for whole bundle: $ codesign -v --deep -s 'Developer ID' CMake.app CMake.app: bundle format unrecognized, invalid, or unsuitable In subcomponent: /private/tmp/CMake.app/Contents/Frameworks/QtCore.framework As I used Qt5 for my own CMake build there is no problem with Qt5 here. But indeed I haven't try to build CMake against last stable Qt 4.8 (that is known to have incorrect layout). Moreover Qt4 seeks hardly for Resources/ folder in framework root, which is not there anymore as it is not obligatory to have Resource/ symlinks. Also QtGui.framework misses Info.plist in Version/4/Resources/. So fix is as simple as: (1) extra symlink Resources/ - Version/Current/Resources/ (for sake of Qt SDK) (2) ensure Info.plist in Version/4/Resources/ I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs. Cheers, -- Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/21/2014 09:17 AM, Adam Strzelecki wrote: First of all this is in fact Qt bug, please follow discussion at: http://lists.qt-project.org/pipermail/development/2014-September/018505.html The patches I provided, especially 55707fd5, were intended to workaround that [snip] I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs. Regardless of where the bug lies, your changes took a packaging case that worked and made it not work. That is a regression. Working around it for the packaging machine of CMake itself is not a solution because it could happen to any project built this way. Please extend your changes to restore successful packaging with no special help by adding whatever workarounds are needed. If the result is not signable when the workarounds are in place that is okay because we couldn't sign before either. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
We have never symlinked Resources/ to Version/Current/Resources since we place icons on other images under the Resources/ folder. The Info.plist has always been placed in the root of Contents, and is still there after the changes. On Tue, Oct 21, 2014 at 9:17 AM, Adam Strzelecki o...@java.pl wrote: Please hold your breath, and don't yet revert my patches because you will end up with bundle that you cannot code-sign anyway for 10.10 and =10.9.5 and it will be bad release that will be rejected by Gatekeeper upon launch. First of all this is in fact Qt bug, please follow discussion at: http://lists.qt-project.org/pipermail/development/2014-September/018505.html The patches I provided, especially 55707fd5, were intended to workaround that so app will code-sign with =10.9.5, especially for Qt case where their frameworks had incorrect layout causing code sign fail for whole bundle: $ codesign -v --deep -s 'Developer ID' CMake.app CMake.app: bundle format unrecognized, invalid, or unsuitable In subcomponent: /private/tmp/CMake.app/Contents/Frameworks/QtCore.framework As I used Qt5 for my own CMake build there is no problem with Qt5 here. But indeed I haven't try to build CMake against last stable Qt 4.8 (that is known to have incorrect layout). Moreover Qt4 seeks hardly for Resources/ folder in framework root, which is not there anymore as it is not obligatory to have Resource/ symlinks. Also QtGui.framework misses Info.plist in Version/4/Resources/. So fix is as simple as: (1) extra symlink Resources/ - Version/Current/Resources/ (for sake of Qt SDK) (2) ensure Info.plist in Version/4/Resources/ I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs. Cheers, -- Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
We have never symlinked Resources/ to Version/Current/Resources since we place icons on other images under the Resources/ folder. The Info.plist has always been placed in the root of Contents, and is still there after the changes. Sorry, maybe I it wasn't clear enough but I am talking about Framework's root and bundled Frameworks layout not app bundle layout here. --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On Tuesday, October 21, 2014 08:22:24 AM Clinton Stimpson wrote: On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote: 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/BP Fr ameworks/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. +1 for a symlink. Handling of framework resources in BundleUtilities.cmake was originally based on the buggy Qt behavior. I think Adam's suggested fix here is good. And for the Qt internal error: Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/ or in the resources directory of your application bundle. The message is incorrect. Qt is actually looking for the resource in QtGui.framework/Resources/ Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/21/2014 09:59 AM, Adam Strzelecki wrote: But assuming we restore Resources/ optional symlink we can circumvent that. And I am working on the patch, just give me few minutes. Great, thanks! -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote: 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/BPFr ameworks/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. +1 for a symlink. Handling of framework resources in BundleUtilities.cmake was originally based on the buggy Qt behavior. I think Adam's suggested fix here is good. Clint 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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Done. Tested with Qt5 Qt4, pushed as f9fcea6803f636adfc9f5755d9c92c802cdc2fb6 to stage/fix-OSX-bundle-rpaths-and-Qt5 (last commit to this branch). @Brad: Shall I make it as separate branch and merge for staging, or you can simply cherry-pick it? --Adam commit f9fcea6803f636adfc9f5755d9c92c802cdc2fb6 Author: Adam Strzelecki o...@java.pl Date: Tue Oct 21 16:42:33 2014 +0200 Ensure framework symlinks and Info.plist exist This restores Qt SDK 4.8 and = 10.6.5 codesign compatibility improving embedding frameworks using correct bundle layout described at: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html 1. If Versions/VERSION/Resources/Info.plist is missing, well known incorrect locations are checked for Info.plist and Info.plist is copied from there, otherwise codesign will fail. 2. Root framework symlinks to binary and Resources are restored to point inside Versions/Current, otherwise Qt 4.8 looking for Resources/ in framework root will fail. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/21/2014 11:34 AM, Adam Strzelecki wrote: @Brad: Shall I make it as separate branch and merge for staging, or you can simply cherry-pick it? I cherry-picked it over on top of the revised/squashed copy of the topic that was merged to 'master': BundleUtilities: Ensure framework symlinks and Info.plist exist http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2 I've merged it for testing in 'next'. Thanks for taking care of this so quickly! -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/10/2014 10:59 AM, Brad King wrote: Everything tested cleanly! Adam, Clinton, thanks for your help bringing this topic to maturity. It was the last non-regression topic I'm planning to take for 3.1. I squashed the fixes and revised commit messages slightly. Then I merged to 'master': Merge topic 'fix-OSX-bundle-rpaths-and-Qt5' http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e We've been having problems getting the 3.1.0-rc1 release binaries to work on machines other than those that built them. Ever since this topic was merged for testing on 2014-09-30, the nightly binaries on OS X have not worked: $ /Volumes/cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents/bin/cmake-gui (works) $ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/ or in the resources directory of your application bundle. The .nib is present in the right place, but the binary does not see them. Comparing the working and broken versions: $ diff -r /Volumes/cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents \ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents | diffstat cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Resources |only cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtCore.framework/Versions/4/Resources |only cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtCore.framework/Versions/Current |only cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Versions/4/Resources |only cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Versions/Current |only ... cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/share/cmake-3.0/Modules/BundleUtilities.cmake | 135 -- cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/share/cmake-3.0/Modules/GetPrerequisites.cmake | 29 +- 16 files changed, 137 insertions(+), 36 deletions(-) we can see that something in the frameworks is different and that one of the only other changes is the BundleUtilities module. Adam, Clinton, please take a look at this. If it cannot be resolved in the next couple days I will have to revert this topic and drop it from the 3.1 release. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
$ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/ or in the resources directory of your application bundle. Did you build against Qt4 SDK taken from official installer? Can you put these both binaries somewhere (zipped) in the cloud? BTW. Any reason to not use Qt5? -- Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Adam Strzelecki wrote: What makes this a Qt issue instead of a generic issue? $ git show 9b98fd52 [Ignoring the qt.conf part] Again, what is Qt-specific about bundling a plugin with an application? What is non-generic about that? Why can't CMake targets communicate what needs to be bundled with them? Why can't some CMake interface consume such information? Why would a install_qt5_bundle function bundle only the platform plugin, but not other plugins? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Picking a message randomly, to respond to - Can someone tell me what this comment is referring to? # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly # Qt5 Mac support is missing there. AFAIR it is about installing correct app bundle PlugIns. Qt provides half-baked CMake support, but some of necessary things still has to be done by user manually, such as installing cocoa platform plugin. --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/13/2014 05:54 AM, Adam Strzelecki wrote: Qt provides half-baked CMake support Side note: this is not a fair characterization of Qt's support for CMake. Qt5 is an outstanding example of how an upstream can make it easy to use a project with CMake even when the upstream itself does not use CMake. Qt5 provides package configuration files for find_package(), and once loaded they provide imported targets with usage requirements. Building a CMake-based project against Qt5 couldn't be much easier IMO. Furthermore, all the CMake-related files come with Qt5 and are maintained there rather than in CMake. This is much easier than Qt4, where FindQt4 in CMake has needed maintenance with every new upstream version. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Side note: this is not a fair characterization of Qt's support for CMake. (…) Furthermore, all the CMake-related files come with Qt5 and are maintained there rather than in CMake. This is much easier than Qt4, where FindQt4 in CMake has needed maintenance with every new upstream version. Of course it is great that THEY provide official CMake support. Maybe half-baked is a bit harsh, but everything goes smooth until you try to run your freshly compiled Qt5 app in on the any other machine that the one it was compiled on. First you realize you miss some Qt libraries you were linking to. Fine, fixup_bundle should do the job, but it doesn't. $ hello.app/Contents/MacOS/hello This application failed to start because it could not find or load the Qt platform plugin cocoa. Available platform plugins are: cocoa, minimal, offscreen. Reinstalling the application may fix this problem. The message isn't really helpful. Finally after seeking googling for an answer you find out that there are platform plugins and there is no function or module that will help you to bundle them and create proper qt.conf. So all apps that are willing to use Qt5 (not Qt4 legacy version) need to have that manually. This is why I call it half-baked. But to be fair, Qt team is really welcoming and open for improvements, I am sure complete support will arrive sooner or later. FYI I was working hard on relocatable Qt SDK for OSX for a while, it is almost complete. We were to release it for 5.4 but due some fancy testing suite problems probably this will be delayed. This was one of the reasons of my rpath support here. Otherwise once Qt SDK uses rpath it will immediately break CMake compatibility. --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Adam Strzelecki wrote: But to be fair, Qt team is really welcoming and open for improvements, I am sure complete support will arrive sooner or later. As the person who wrote what Qt ships, I can say that it won't be 'complete' sooner or later unless someone with enough interest communicates/contributes what is missing. I don't have the requisite mac experience. I also think there might be a generic solution (or partial solution) to implement in CMake first (an interface for determining the package dependencies perhaps, etc). What makes this a Qt issue instead of a generic issue? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/09/2014 11:19 AM, Brad King wrote: I merged it for testing in 'next'. Everything tested cleanly! Adam, Clinton, thanks for your help bringing this topic to maturity. It was the last non-regression topic I'm planning to take for 3.1. I squashed the fixes and revised commit messages slightly. Then I merged to 'master': Merge topic 'fix-OSX-bundle-rpaths-and-Qt5' http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Clinton Stimpson wrote: Another justification for that is if a target does not link to any libraries with an @rpath id, it is still useful to have an rpath to support dlopen(@rpath/somelib). Picking a message randomly, to respond to - Can someone tell me what this comment is referring to? # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly # Qt5 Mac support is missing there. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Adam,
On 10/08/2014 12:17 PM, Clinton Stimpson wrote:
Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with
@rpath on OS X 10.5. Perhaps it'll recognize there is no need to change
rpaths.
The BundleUtilities test still fails on OS X 10.5:
http://open.cdash.org/testDetails.php?test=285651145build=3522021
-- 6/10: fixing up
'/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
install_name_tool: more than one input file specified
(/.../Tests/BundleUtilities/testdir1 and -delete_rpath)
Usage: install_name_tool [-change old new] ... [-id name] input
Clinton's changes in his rpath-osx-10_6 extension topic to yours teach
other uses of -delete_rpath to warn on OS X 10.5 and skip deletion.
I think something similar will be needed here. Please investigate.
Meanwhile, on my local OS X 10.9 machine I added this patch:
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index eedab44..80e5d3b 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath
dirs)
#
if(changes)
execute_process(COMMAND install_name_tool ${changes}
${resolved_embedded_item})
+message(STATUS CHANGE install_name_tool ${changes}
\${resolved_embedded_item}\)
endif()
endfunction()
From the test output I can see that it is trying to delete several
rpath entries that do not exist and therefore do not need deletion.
How is the list chosen for each binary?
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
- Original Message -
On 10/08/2014 11:05 AM, clin...@elemtech.com wrote:
I pushed more fixes for this. Instead of requiring 10.6,
I took the other path of warning when rpaths need changed
at install time and skip it.
This should also fix the CMP0042 test which started failing.
Thanks. The message is currently:
+ msg WARNING: Target \ this-Target-GetName()
+ \ has runtime paths which cannot be changed during install.
+ To change runtime paths, OS X version 10.6 or newer is
required.
+ Therefore, runtime paths will not be changed when
installing.;
+ cmSystemTools::Message(msg.str().c_str(), Warning);
Can that be changed to an IssueMessage, possibly on a cmMakefile
for at least a little context? Also it should suggest using
CMAKE_BUILD_WITH_INSTALL_RPATH.
By the way, Brad, your change to require 10.6 for the
BundleUtilities test is no longer required on the rpath-osx-10_6 topic.
I thought it was a missing piece of your original change.
Since you've reverted that I've now reverted mine so we'll
see how testing goes.
However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5
topic.
I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to
make local testing of both together easier. Please base the
above-requested fixes on:
OSX: Warn when attempting to change runtime paths on OS X 10.5
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55
Adam,
I was looking at the BundleUtilities failure after the above fixes, and I
noticed it unconditionally removes rpaths.
Is there a reason for that?
If the user does
set_target_properties(testbundleutils1 module1 PROPERTIES
INSTALL_RPATH ${CMAKE_CURRENT_BINARY_DIR}/testdir1
BUILD_WITH_INSTALL_RPATH 1)
The new BundleUtilities.cmake will strip that rpath.
The attempt to strip those rpaths fails on OS X 10.5, because install_name_tool
does not recognize the -delete_rpath.
The test fails because the -id and -change portion of the install_name_tool
command is prevented by the error from the use of -delete_rpath.
Perhaps we can separate the -delete_rpath part into its own call to
install_name_tool. If it fails, the failure can be ignored (as it previously
ignored install_name_tool failures). Or maybe there is another idea.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
- Original Message -
Adam,
On 10/08/2014 12:17 PM, Clinton Stimpson wrote:
Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with
@rpath on OS X 10.5. Perhaps it'll recognize there is no need to change
rpaths.
The BundleUtilities test still fails on OS X 10.5:
http://open.cdash.org/testDetails.php?test=285651145build=3522021
-- 6/10: fixing up
'/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
install_name_tool: more than one input file specified
(/.../Tests/BundleUtilities/testdir1 and -delete_rpath)
Usage: install_name_tool [-change old new] ... [-id name] input
Clinton's changes in his rpath-osx-10_6 extension topic to yours teach
other uses of -delete_rpath to warn on OS X 10.5 and skip deletion.
I think something similar will be needed here. Please investigate.
Meanwhile, on my local OS X 10.9 machine I added this patch:
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index eedab44..80e5d3b 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath
dirs)
#
if(changes)
execute_process(COMMAND install_name_tool ${changes}
${resolved_embedded_item})
+message(STATUS CHANGE install_name_tool ${changes}
\${resolved_embedded_item}\)
endif()
endfunction()
From the test output I can see that it is trying to delete several
rpath entries that do not exist and therefore do not need deletion.
How is the list chosen for each binary?
Brad,
When I do the same message(), I don't see deletion of rpaths which do not exist.
I see deletions of rpaths which do exist as defined in the CMakeLists.txt file:
set_target_properties(testbundleutils1 module1 PROPERTIES
INSTALL_RPATH ${CMAKE_CURRENT_BINARY_DIR}/testdir1
BUILD_WITH_INSTALL_RPATH 1)
But, I'm wondering if INSTALL_RPATH should only be effective on OS X if
MACOSX_RPATH is set.
Currently MACOSX_RPATH determines whether a target uses @rpath for its id,
which can result in rpaths for a consumer.
In other words, whether a target has rpaths is determined by the use of @rpath
in its dependencies.
What do you think about the case of INSTALL_RPATH?
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/09/2014 10:16 AM, clin...@elemtech.com wrote: When I do the same message(), I don't see deletion of rpaths which do not exist. I see them for libshared and libshared2 which have SKIP_BUILD_RPATH. But, I'm wondering if INSTALL_RPATH should only be effective on OS X if MACOSX_RPATH is set. Currently MACOSX_RPATH determines whether a target uses @rpath for its id, which can result in rpaths for a consumer. In other words, whether a target has rpaths is determined by the use of @rpath in its dependencies. What do you think about the case of INSTALL_RPATH? If any dependencies have @rpath then the RPATH of a target is meaningful, and INSTALL_RPATH is how the actual search paths listed in the RPATH are to be set. INSTALL_RPATH is orthogonal to MACOSX_RPATH. The affect different fields of their target. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
I was looking at the BundleUtilities failure after the above fixes, and I noticed it unconditionally removes paths. It does that because all bundles frameworks/libraries are referenced by @executable/loader_path and all @rpath references will be replaced, so there no point to have LC_RPATH in executables that will likely point to absolute old library locations. Please note that this is just an extension to existing BundleUtilities behavior. I intentionally didn't want to support or add an option to bundle framework using @path + LC_PATH. --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On Thursday, October 09, 2014 10:27:32 AM Brad King wrote: On 10/09/2014 10:16 AM, clin...@elemtech.com wrote: When I do the same message(), I don't see deletion of rpaths which do not exist. I see them for libshared and libshared2 which have SKIP_BUILD_RPATH. But, I'm wondering if INSTALL_RPATH should only be effective on OS X if MACOSX_RPATH is set. Currently MACOSX_RPATH determines whether a target uses @rpath for its id, which can result in rpaths for a consumer. In other words, whether a target has rpaths is determined by the use of @rpath in its dependencies. What do you think about the case of INSTALL_RPATH? If any dependencies have @rpath then the RPATH of a target is meaningful, and INSTALL_RPATH is how the actual search paths listed in the RPATH are to be set. INSTALL_RPATH is orthogonal to MACOSX_RPATH. The affect different fields of their target. Another justification for that is if a target does not link to any libraries with an @rpath id, it is still useful to have an rpath to support dlopen(@rpath/somelib). Thanks, Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
FYI pushed e646a14f61 BundleUtilities: Check install_name_tool has -delete_rpath which is safest way to check if we can use -delete_rpath as it was introduced somewhere in 10.6 SDK, but there's no guarantee what SDK user has even it runs more recent OSX. --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/09/2014 11:14 AM, Adam Strzelecki wrote: FYI pushed e646a14f61 BundleUtilities: Check install_name_tool has -delete_rpath which is safest way to check if we can use Thanks. I moved the commit over on top of the rpath-osx-10_6 topic and then removed that topic. For now fix-OSX-bundle-rpaths-and-Qt5 will contain all these related changes. I merged it for testing in 'next'. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
- Original Message -
- Original Message -
On 10/06/2014 10:36 AM, Adam Strzelecki wrote:
Sure, I think it would be good to require 10.6.
Moreover I believe nobody nowadays builds for 10.5 on 10.5.
Perhaps no one has to build that way for deployment but there could
still be people just building for their own host as the only computer
they have. The fact that our dashboard reported this problem means
we are testing that case.
Clinton, I don't have a 10.5 machine anymore and the test is failing
on yours. Please take whatever action you feel is appropriate to
resolve the test failure on that machine. This could mean either
disabling rpath altogether on 10.5 or changing the new hunk:
+ foreach(rpath ${${ikey}_RPATHS})
+set(changes ${changes} -delete_rpath ${rpath})
+ endforeach()
to warn and skip removal when hosted on 10.5. Or another option you
find.
This needs to be resolved in the next day or two or the topic won't
be in CMake 3.1.
Thanks,
-Brad
I don't have a 10.5 machine, but I've put in a commit which I hope solves the
problem.
36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater.
I pushed more fixes for this. Instead of requiring 10.6, I took the other path
of warning when rpaths need changed at install time and skip it.
This should also fix the CMP0042 test which started failing.
By the way, Brad, your change to require 10.6 for the BundleUtilities test is
no longer required on the rpath-osx-10_6 topic.
However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/08/2014 11:05 AM, clin...@elemtech.com wrote: I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it. This should also fix the CMP0042 test which started failing. Thanks. The message is currently: + msg WARNING: Target \ this-Target-GetName() + \ has runtime paths which cannot be changed during install. + To change runtime paths, OS X version 10.6 or newer is required. + Therefore, runtime paths will not be changed when installing.; + cmSystemTools::Message(msg.str().c_str(), Warning); Can that be changed to an IssueMessage, possibly on a cmMakefile for at least a little context? Also it should suggest using CMAKE_BUILD_WITH_INSTALL_RPATH. By the way, Brad, your change to require 10.6 for the BundleUtilities test is no longer required on the rpath-osx-10_6 topic. I thought it was a missing piece of your original change. Since you've reverted that I've now reverted mine so we'll see how testing goes. However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic. I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to make local testing of both together easier. Please base the above-requested fixes on: OSX: Warn when attempting to change runtime paths on OS X 10.5 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55 Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On Wednesday, October 08, 2014 11:17:03 AM Brad King wrote: On 10/08/2014 11:05 AM, clin...@elemtech.com wrote: I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it. This should also fix the CMP0042 test which started failing. Thanks. The message is currently: + msg WARNING: Target \ this-Target-GetName() + \ has runtime paths which cannot be changed during install. + To change runtime paths, OS X version 10.6 or newer is required. + Therefore, runtime paths will not be changed when installing.; + cmSystemTools::Message(msg.str().c_str(), Warning); Can that be changed to an IssueMessage, possibly on a cmMakefile for at least a little context? Also it should suggest using CMAKE_BUILD_WITH_INSTALL_RPATH. Fixed. By the way, Brad, your change to require 10.6 for the BundleUtilities test is no longer required on the rpath-osx-10_6 topic. I thought it was a missing piece of your original change. Since you've reverted that I've now reverted mine so we'll see how testing goes. Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with @rpath on OS X 10.5. Perhaps it'll recognize there is no need to change rpaths. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/07/2014 12:34 AM, clin...@elemtech.com wrote: I don't have a 10.5 machine Oops, I must have mixed up my browser tabs on that one. but I've put in a commit which I hope solves the problem. 36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater. Thanks! -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/04/2014 11:37 AM, Adam Strzelecki wrote: I've applied your suggestions about quoting and used portable (POSIX compliant) find call that should work now on any system. Thanks. On 10/05/2014 03:35 PM, Adam Strzelecki wrote: Correct me if I am wrong but it seems CDash reports no further problems with my changes. It's better, but the BundleUtilities test fails on OS X 10.5: http://open.cdash.org/testDetails.php?test=285651145build=3517533 -- 6/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input -- 7/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so' install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input From this message it looks like the install_name_tool does not support -delete_rpath. IIRC @rpath was first added in OS X 10.5 so it looks like that part had not yet matured. Use of -delete_rpath was previously added at install-time here: OS X: Add RPATH support for Mac. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94e7fef2 so I think this problem existed before but was not exposed by tests. Clinton, what do you think of changing the Darwin.cmake test for enabling @rpath support to require OS X 10.6 instead of 10.5? Otherwise we may be leaking build tree RPATH entries into installed files on 10.5. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
- Original Message - On 10/04/2014 11:37 AM, Adam Strzelecki wrote: I've applied your suggestions about quoting and used portable (POSIX compliant) find call that should work now on any system. Thanks. On 10/05/2014 03:35 PM, Adam Strzelecki wrote: Correct me if I am wrong but it seems CDash reports no further problems with my changes. It's better, but the BundleUtilities test fails on OS X 10.5: http://open.cdash.org/testDetails.php?test=285651145build=3517533 -- 6/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input -- 7/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so' install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input From this message it looks like the install_name_tool does not support -delete_rpath. IIRC @rpath was first added in OS X 10.5 so it looks like that part had not yet matured. Use of -delete_rpath was previously added at install-time here: OS X: Add RPATH support for Mac. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94e7fef2 so I think this problem existed before but was not exposed by tests. Clinton, what do you think of changing the Darwin.cmake test for enabling @rpath support to require OS X 10.6 instead of 10.5? Otherwise we may be leaking build tree RPATH entries into installed files on 10.5. Sure, I think it would be good to require 10.6. We also have uses of the -delete_rpath/-add_rpath parameters in cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or greater. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Sure, I think it would be good to require 10.6. We also have uses of the -delete_rpath/-add_rpath parameters in cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or greater. Moreover I believe nobody nowadays builds for 10.5 on 10.5. Since 10.6 with Xcode 3 supports 10.5 PPC and Apple allows virtualization of 10.6 Server, so if anyone still targets PPC on 10.5 or earlier then 10.6 is natural choice. --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/06/2014 10:36 AM, Adam Strzelecki wrote:
Sure, I think it would be good to require 10.6.
Moreover I believe nobody nowadays builds for 10.5 on 10.5.
Perhaps no one has to build that way for deployment but there could
still be people just building for their own host as the only computer
they have. The fact that our dashboard reported this problem means
we are testing that case.
Clinton, I don't have a 10.5 machine anymore and the test is failing
on yours. Please take whatever action you feel is appropriate to
resolve the test failure on that machine. This could mean either
disabling rpath altogether on 10.5 or changing the new hunk:
+ foreach(rpath ${${ikey}_RPATHS})
+set(changes ${changes} -delete_rpath ${rpath})
+ endforeach()
to warn and skip removal when hosted on 10.5. Or another option you
find.
This needs to be resolved in the next day or two or the topic won't
be in CMake 3.1.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
- Original Message -
On 10/06/2014 10:36 AM, Adam Strzelecki wrote:
Sure, I think it would be good to require 10.6.
Moreover I believe nobody nowadays builds for 10.5 on 10.5.
Perhaps no one has to build that way for deployment but there could
still be people just building for their own host as the only computer
they have. The fact that our dashboard reported this problem means
we are testing that case.
Clinton, I don't have a 10.5 machine anymore and the test is failing
on yours. Please take whatever action you feel is appropriate to
resolve the test failure on that machine. This could mean either
disabling rpath altogether on 10.5 or changing the new hunk:
+ foreach(rpath ${${ikey}_RPATHS})
+set(changes ${changes} -delete_rpath ${rpath})
+ endforeach()
to warn and skip removal when hosted on 10.5. Or another option you
find.
This needs to be resolved in the next day or two or the topic won't
be in CMake 3.1.
Thanks,
-Brad
I don't have a 10.5 machine, but I've put in a commit which I hope solves the
problem.
36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 09/30/2014 01:44 PM, Adam Strzelecki wrote:
Please merge the topic to 'next' for testing when you're ready.
We can at least see if the dashboard stays clean with it.
Done.
Since this was merged the dashboard has reported several failing
instances of the BundleUtilities test. They have errors like:
/usr/bin/find: invalid mode '+0111'
CMake Error at .../Modules/BundleUtilities.cmake:395 (string):
string sub-command REPLACE requires at least four arguments.
Please extend the topic with a fix. Also use quoting like:
- string(REPLACE \n ; file_list ${file_list})
+ string(REPLACE \n ; file_list ${file_list})
to make sure the command runs when the file list is empty.
After extending the topic please merge to 'next' again and
check if it fixes the dashboard.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Hi Folks, Picking up from the end of an earlier thread: [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focus=11016 Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to 'next' for testing? Clinton, have your comments been addressed? Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On Tuesday, September 30, 2014 11:37:27 AM Brad King wrote: Hi Folks, Picking up from the end of an earlier thread: [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focu s=11016 Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to 'next' for testing? Clinton, have your comments been addressed? Thanks, -Brad My concerns of breaking backward compatibility were already addressed. However, I do wish there is a test for this. Although the commits target OS X, I would like to see some proof that the API changes in GetPrerequisites for supporting rpaths will work on other platforms such as Linux. A test for both OS X and Linux will help justify the API changes. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
A test for both OS X and Linux will help justify the API changes. Well. All I can say that failing tests were already addressed in latest version of this branch. Also it does not break existing functions signature or behavior. All new parameters are optional. I have no other means to prove that everything is OK. --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 09/30/2014 12:24 PM, Adam Strzelecki wrote: I have no other means to prove that everything is OK. Please merge the topic to 'next' for testing when you're ready. We can at least see if the dashboard stays clean with it. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Please merge the topic to 'next' for testing when you're ready. We can at least see if the dashboard stays clean with it. Done. --Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
