Bug 139212 – Switch from using PLATFORM_NAME to SDK selectors in ANGLE, bmalloc, gtest, JavaScriptCore, WTF

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[David Kilzer (:ddkilzer)]

Switch from using PLATFORM_NAME to SDK selectors in the ANGLE, bmalloc, gtest, JavaScriptCore, and WTF projects.

See also:  Bug 138813: FeatureDefines.xcconfig: Switch from using PLATFORM_NAME to SDK selectors

[David Kilzer (:ddkilzer)]

Created attachment 242466 [details]
Patch v1

[WebKit Commit Bot]

Note that there are important steps to take when updating ANGLE. See http://trac.webkit.org/wiki/UpdatingANGLE

[Geoffrey Garen]

Comment on attachment 242466 [details]
Patch v1

r=me

[WebKit Commit Bot]

Comment on attachment 242466 [details]
Patch v1

Rejecting attachment 242466 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-02', 'build', '--no-clean', '--no-update', '--build-style=release', '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
ROJECT ANGLE WITH CONFIGURATION Release ===

Check dependencies
Base.xcconfig line 1: Unable to find included file "<DEVELOPER_DIR>/AppleInternal/XcodeConfig/AspenFamily.xcconfig"
Base.xcconfig line 2: Unable to find included file "../../../../../Internal/Configurations/HaveInternalSDK.xcconfig"
error: There is no SDK with the name or path '/Volumes/Data/EWS/WebKit/Source/ThirdParty/ANGLE/macosx.internal'

** BUILD FAILED **


The following build commands failed:
	Check dependencies
(1 failure)

Full output: http://webkit-queues.appspot.com/results/6689867459198976

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> Comment on attachment 242466 [details]
> Patch v1
> 
> Rejecting attachment 242466 [details] from commit-queue.
> 
> error: There is no SDK with the name or path
> '/Volumes/Data/EWS/WebKit/Source/ThirdParty/ANGLE/macosx.internal'

It would appear that the 10.8 SDK doesn't support the [sdk=macosx*] selectors.  Or perhaps not wildcards.  Need to test further.

[David Kilzer (:ddkilzer)]

Comment on attachment 242466 [details]
Patch v1

Clearing r+ flag.

[David Kilzer (:ddkilzer)]

Created attachment 242538 [details]
Patch v2 (Testing 10.8 fix for ANGLE project; DO NOT REVIEW)

[David Kilzer (:ddkilzer)]

(In reply to comment #5)
> (In reply to comment #4)
> > Comment on attachment 242466 [details]
> > Patch v1
> > 
> > Rejecting attachment 242466 [details] from commit-queue.
> > 
> > error: There is no SDK with the name or path
> > '/Volumes/Data/EWS/WebKit/Source/ThirdParty/ANGLE/macosx.internal'
> 
> It would appear that the 10.8 SDK doesn't support the [sdk=macosx*]
> selectors.  Or perhaps not wildcards.  Need to test further.


WTF?!  This is a bug, right?


ANGLE variables defined with Patch v1:

    export CONFIGURATION=Release
    export SDKROOT=/Volumes/Data/EWS/WebKit/Source/ThirdParty/ANGLE/macosx.internal
    export SDKROOT_macosx_=macosx
    export SDKROOT_macosx_YES=macosx.internal
    export USE_INTERNAL_SDK_Production=YES

SDKROOT[sdk=macosx*] = $(SDKROOT_macosx_$(USE_INTERNAL_SDK));
SDKROOT_macosx_ = macosx;
SDKROOT_macosx_YES = macosx.internal;

FAIL: SDKROOT is set to macosx.internal even though USE_INTERNAL_SDK is not defined!


ANGLE variables defined with Patch v2:

    setenv CONFIGURATION Release
    setenv SDKROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
    setenv SDKROOT_macosx macosx
    setenv SDKROOT_macosx_ macosx
    setenv SDKROOT_macosx_YES macosx.internal
    setenv USE_INTERNAL_SDK_Production YES

SDKROOT = $(SDKROOT_$(PLATFORM_NAME));
SDKROOT[sdk=iphoneos*] = $(SDKROOT);
SDKROOT[sdk=iphonesimulator*] = $(SDKROOT);
SDKROOT_macosx = $(SDKROOT_macosx_$(USE_INTERNAL_SDK));
SDKROOT_macosx_ = macosx;
SDKROOT_macosx_YES = macosx.internal;

SUCCESS: SDKROOT is set to macosx (and expanded later).

[David Kilzer (:ddkilzer)]

And why does one build use "export" but the other uses "setenv" for the same build phase script?!

[Mark Rowe (bdash)]

(In reply to comment #9)
> And why does one build use "export" but the other uses "setenv" for the same
> build phase script?!

I think there are two different Xcode versions in play.

https://webkit-queues.appspot.com/results/4892086490890240
    setenv XCODE_PRODUCT_BUILD_VERSION 5A1413

https://webkit-queues.appspot.com/results/6689867459198976
    export XCODE_PRODUCT_BUILD_VERSION=5B1008

That's Xcode 5.0 (webkit-ews-03) and 5.1.1 (webkit-cq-02) respectively.

[David Kilzer (:ddkilzer)]

(In reply to comment #10)
> (In reply to comment #9)
> > And why does one build use "export" but the other uses "setenv" for the same
> > build phase script?!
> 
> I think there are two different Xcode versions in play.
> 
> https://webkit-queues.appspot.com/results/4892086490890240
>     setenv XCODE_PRODUCT_BUILD_VERSION 5A1413
> 
> https://webkit-queues.appspot.com/results/6689867459198976
>     export XCODE_PRODUCT_BUILD_VERSION=5B1008
> 
> That's Xcode 5.0 (webkit-ews-03) and 5.1.1 (webkit-cq-02) respectively.

Bazinga!  Xcode 5.0 does not have the bug, bug Xcode 5.1.1 does.

The bug appears to be that any Xcode variable that mixes both the selector syntax ([sdk=blah*]) and a nested variable in the value is simply not set.

Here's another example:

MACOSX_DEPLOYMENT_TARGET[sdk=macosx*] = $(MACOSX_DEPLOYMENT_TARGET_macosx_$(TARGET_MAC_OS_X_VERSION_MAJOR));
MACOSX_DEPLOYMENT_TARGET_macosx_1080 = 10.8;
MACOSX_DEPLOYMENT_TARGET_macosx_1090 = 10.9;
MACOSX_DEPLOYMENT_TARGET_macosx_101000 = 10.10;
MACOSX_DEPLOYMENT_TARGET_macosx_101100 = 10.11;

On Xcode 5.1.1, MACOSX_DEPLOYMENT_TARGET is never set:

    export MACOSX_DEPLOYMENT_TARGET_101000=10.10
    export MACOSX_DEPLOYMENT_TARGET_101100=10.11
    export MACOSX_DEPLOYMENT_TARGET_1080=10.8
    export MACOSX_DEPLOYMENT_TARGET_1090=10.9

Bug on Xcode 5.0, MACOSX_DEPLOYMENT_TARGET is set:

    setenv MACOSX_DEPLOYMENT_TARGET 10.8
    setenv MACOSX_DEPLOYMENT_TARGET_101000 10.10
    setenv MACOSX_DEPLOYMENT_TARGET_101100 10.11
    setenv MACOSX_DEPLOYMENT_TARGET_1080 10.8
    setenv MACOSX_DEPLOYMENT_TARGET_1090 10.9

[David Kilzer (:ddkilzer)]

(In reply to comment #11)
> Bug on Xcode 5.0, MACOSX_DEPLOYMENT_TARGET is set:

That should read "BUT on Xcode 5.0, MACOSX_DEPLOYMENT_TARGET is set:".

[David Kilzer (:ddkilzer)]

Also, by sheer coincidence, the only variable that is not set properly in FeatureDefines.xcconfig (Bug 138813) on 10.8 is ENABLE_WEB_REPLAY:

ENABLE_WEB_REPLAY[sdk=macosx*] = $(ENABLE_WEB_REPLAY_macosx_$(CONFIGURATION));
ENABLE_WEB_REPLAY_macosx_Debug = ENABLE_WEB_REPLAY;
ENABLE_WEB_REPLAY_macosx_Release = ENABLE_WEB_REPLAY;
ENABLE_WEB_REPLAY_macosx_Production = ;

Every other time the sdks selector syntax is used with sub-variable syntax, we explicitly don't define a value for 10.8 (because the feature is disabled).

[David Kilzer (:ddkilzer)]

Created attachment 242562 [details]
Patch v3 (Testing 10.8 fix for SDKROOT variable; DO NOT REVIEW)

[David Kilzer (:ddkilzer)]

Created attachment 242651 [details]
Patch v4 (with Xcode 5.1.1/OS X 10.8 workaround)

[Joseph Pecoraro]

Comment on attachment 242651 [details]
Patch v4 (with Xcode 5.1.1/OS X 10.8 workaround)

View in context: https://bugs.webkit.org/attachment.cgi?id=242651&action=review

r=me

> Source/JavaScriptCore/Configurations/ToolExecutable.xcconfig:41
> +CLANG_ENABLE_OBJC_ARC_i386[sdk=iphonesimulator*] = YES; # For iOS Simulator version 4.0 and greater

Maybe we can remove the comment now.

[David Kilzer (:ddkilzer)]

Committed r177027: <http://trac.webkit.org/changeset/177027>

[David Kilzer (:ddkilzer)]

(In reply to comment #16)
> Comment on attachment 242651 [details]
> Patch v4 (with Xcode 5.1.1/OS X 10.8 workaround)
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=242651&action=review
> 
> r=me
> 
> > Source/JavaScriptCore/Configurations/ToolExecutable.xcconfig:41
> > +CLANG_ENABLE_OBJC_ARC_i386[sdk=iphonesimulator*] = YES; # For iOS Simulator version 4.0 and greater
> 
> Maybe we can remove the comment now.

Removed!

[David Kilzer (:ddkilzer)]

(In reply to comment #17)
> Committed r177027: <http://trac.webkit.org/changeset/177027>

Follow-up build fix in r177210: <http://trac.webkit.org/changeset/177210>

(In reply to comment #17)
> Committed r177027: <http://trac.webkit.org/changeset/177027>

This caused bug 139950.