Proposed fix to restore functionality for
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/
while retaining the current hack when CMAKE_OSX_DEPLOYMENT_TARGET is
not set to an empty string.
On Sun, Oct 30, 2016 at 3:23 PM, Jack Howarth
wrote:
>
On 30/10/2016 20:37, Jack Howarth wrote:
> Proposed fix to restore functionality for
> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/
> while retaining the current hack when CMAKE_OSX_DEPLOYMENT_TARGET is
> not set to an empty string.
Thanks for the patch but it is breaking
On 30/10/2016 20:23, Jack Howarth wrote:
> Gregor,
> While I still think your hack to obtain the versioned SDK is
> wrong because it relies on passing invalid arguments to 'xcodebuild
> -sdk', the following change restores the expected behavior for
> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=""
Hello Howarth,
I'm sorry that I broke your use case with that patch. The problem I have
with maintaining the Xcode / Darwin code is that it is full of backward
compatibility and unknown, undocumented use cases. That makes it
sometimes hard to foresee consequences.
On 30/10/2016 19:04, Jack
Gregor,
While I still think your hack to obtain the versioned SDK is
wrong because it relies on passing invalid arguments to 'xcodebuild
-sdk', the following change restores the expected behavior for
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/
while allowing your hack
Gregor,
The change in
https://cmake.org/gitweb?p=cmake.git;a=patch;h=540815eec2b83a8b43689580c54e8950d9f5868b
is logically flawed because it allows...
COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path
to be passed ${CMAKE_OSX_SYSROOT} containing "/" which isn't a valid
argument for
On 30/10/2016 18:33, Jack Howarth wrote:
> Gregor,
> Your commit of...
>
> https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b
>
> has caused a major regression in cmake 3.7.0 as it no longer properly
> honors the combination...
>
>
One other comment. For new Xcode releases on the prior OS release (eg
Xcode 8 on 10.11), the SDK files installed in / by the Command Line
Tools are actually those for the 10.11 SDK and *not* those from the
10.12 SDK. This is why the Xcode 8 release lacks a Command Line Tools
package for 10.11
2016-08-17 16:47 GMT+03:00 Brad King :
> I squashed in one warning fix:
>
> Windows: Encode child process output to internally-used encoding
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12924660
>
> However, then I had to revert the change from `next` because it
>
The change...
--- cmake-3.6.2/Modules/Platform/Darwin-Initialize.cmake 2016-09-07
10:11:58.0 -0400
+++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake
2016-10-19 09:47:45.0 -0400
@@ -125,8 +125,10 @@
set(_CMAKE_OSX_SYSROOT_ORIG "")
endif()
Gregor,
This is also a severe regression because if forces the cmake
users to build against the 10.12 SDK on 10.11 which is not well tested
for backward compatibility on 10.11. Your change makes it impossible
to build against the SDK in / installed by the Xcode Command Line
Tools package.
Gregor,
Your commit of...
https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b
has caused a major regression in cmake 3.7.0 as it no longer properly
honors the combination...
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/
This is
12 matches
Mail list logo