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
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:
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...
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
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
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:
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
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
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
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:
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
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:
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:
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
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
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':
$
/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
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
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
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
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
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
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
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?
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
- 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.
- 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
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
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
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
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
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
- 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
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:
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
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
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
- 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
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
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
- 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
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
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
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
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
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
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
47 matches
Mail list logo
