Remove the need for defining USE_NEW_BUILD_SYSTEM

https://bugs.webkit.org/show_bug.cgi?id=215439 Reviewed by Darin Adler. When building WebKit for XCBuild, we currently require that the external build system (such as the Makefile, build-webkit, etc.) defines the USE_NEW_BUILD_SYSTEM=YES build setting. This build setting controls parts of our build instructions that are sensitive to when XCBuild or the Legacy build system are being used. Notably, we need to know when to use our custom “copy and modify” scripts with copying certain header files (used with the Legacy build system) vs. using the enhanced Copy Headers build phase that’s enabled with APPLY_RULES_IN_COPY_HEADERS=YES (introduced with and used by XCBuild). The choice of which method to copy headers is used is controlled by USE_NEW_BUILD_SYSTEM. There is no built-in build setting that we can probe to help us determine which approach to take when copying and modifying headers, which is why we need to define USE_NEW_BUILD_SYSTEM ourselves. But it turns out that we can *detect* which build system is being used by taking advantage of a subtle difference between the two systems. As noted in: https://developer.apple.com/documentation/xcode-release-notes/build-system-release-notes-for-xcode-10 “When an .xcconfig file contains multiple assignments of the same build setting, later assignments using $(inherited) or $(<setting_name>) will inherit from earlier assignments in the .xcconfig. The legacy build system caused every use of $(inherited) or $(<setting_name>) skip any other values defined within the .xcconfig.” This difference can be exploited as follows: WK_WHICH_BUILD_SYSTEM = not_ WK_WHICH_BUILD_SYSTEM = $(inherited)legacy WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM)) WK_USE_NEW_BUILD_SYSTEM_legacy = NO WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES We can then use WK_USE_NEW_BUILD_SYSTEM where we used to use the externally-defined USE_NEW_BUILD_SYSTEM. .: * Makefile.shared: Source/JavaScriptCore: * Configurations/Base.xcconfig: * Configurations/JavaScriptCore.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: Source/ThirdParty/ANGLE: * ANGLE.xcodeproj/project.pbxproj: * Configurations/ANGLE-dynamic.xcconfig: * Configurations/ANGLE-static.xcconfig: * Configurations/Base.xcconfig: Source/WebKit: No new tests -- no new or changed functionality. * Configurations/Base.xcconfig: * Configurations/WebKit.xcconfig: * WebKit.xcodeproj/project.pbxproj: Source/WebKitLegacy: * WebKitLegacy.xcodeproj/project.pbxproj: Source/WebKitLegacy/mac: * Configurations/Base.xcconfig: * Configurations/WebKitLegacy.xcconfig: Tools: * Scripts/build-webkit: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@265602 268f45cc-cd09-0410-ab3c-d52691b4dbfc
yury-s · Aug 13, 2020 · bb322c6 · bb322c6
1 parent 66a3cb3
commit bb322c6
Show file tree

Hide file tree

Showing 22 changed files with 391 additions and 26 deletions.
diff --git a/ChangeLog b/ChangeLog
@@ -1,3 +1,51 @@
+2020-08-12  Keith Rollin  <[email protected]>
+
+        Remove the need for defining USE_NEW_BUILD_SYSTEM
+        https://bugs.webkit.org/show_bug.cgi?id=215439
+
+        Reviewed by Darin Adler.
+
+        When building WebKit for XCBuild, we currently require that the
+        external build system (such as the Makefile, build-webkit, etc.)
+        defines the USE_NEW_BUILD_SYSTEM=YES build setting. This build setting
+        controls parts of our build instructions that are sensitive to when
+        XCBuild or the Legacy build system are being used. Notably, we need to
+        know when to use our custom “copy and modify” scripts with copying
+        certain header files (used with the Legacy build system) vs. using the
+        enhanced Copy Headers build phase that’s enabled with
+        APPLY_RULES_IN_COPY_HEADERS=YES (introduced with and used by XCBuild).
+        The choice of which method to copy headers is used is controlled by
+        USE_NEW_BUILD_SYSTEM.
+
+        There is no built-in build setting that we can probe to help us
+        determine which approach to take when copying and modifying headers,
+        which is why we need to define USE_NEW_BUILD_SYSTEM ourselves. But it
+        turns out that we can *detect* which build system is being used by
+        taking advantage of a subtle difference between the two systems. As
+        noted in:
+
+            https://developer.apple.com/documentation/xcode-release-notes/build-system-release-notes-for-xcode-10
+
+            “When an .xcconfig file contains multiple assignments of the same
+             build setting, later assignments using $(inherited) or
+             $(<setting_name>) will inherit from earlier assignments in the
+             .xcconfig. The legacy build system caused every use of
+             $(inherited) or $(<setting_name>) skip any other values defined
+             within the .xcconfig.”
+
+        This difference can be exploited as follows:
+
+            WK_WHICH_BUILD_SYSTEM = not_
+            WK_WHICH_BUILD_SYSTEM = $(inherited)legacy
+            WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM))
+            WK_USE_NEW_BUILD_SYSTEM_legacy = NO
+            WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES
+
+        We can then use WK_USE_NEW_BUILD_SYSTEM where we used to use the
+        externally-defined USE_NEW_BUILD_SYSTEM.
+
+        * Makefile.shared:
+
 2020-08-11  Philippe Normand  <[email protected]>
 
         [GStreamer] gst-full standalone library support

diff --git a/Makefile.shared b/Makefile.shared
@@ -42,12 +42,9 @@ ifeq ($(findstring UseNewBuildSystem,$(ARGS)),)
 	ifeq ($(CAN_USE_XCBUILD),1)
 		# Temporarily disable default use of XCBuild until issues with it are ironed out.
 		#XCODE_OPTIONS += -UseNewBuildSystem=YES
-		#XCODE_OPTIONS += USE_NEW_BUILD_SYSTEM=YES
 		XCODE_OPTIONS += -UseNewBuildSystem=NO
-		XCODE_OPTIONS += USE_NEW_BUILD_SYSTEM=NO
 	else
 		XCODE_OPTIONS += -UseNewBuildSystem=NO
-		XCODE_OPTIONS += USE_NEW_BUILD_SYSTEM=NO
 	endif
 endif
 

diff --git a/Source/JavaScriptCore/ChangeLog b/Source/JavaScriptCore/ChangeLog
@@ -1,3 +1,53 @@
+2020-08-12  Keith Rollin  <[email protected]>
+
+        Remove the need for defining USE_NEW_BUILD_SYSTEM
+        https://bugs.webkit.org/show_bug.cgi?id=215439
+
+        Reviewed by Darin Adler.
+
+        When building WebKit for XCBuild, we currently require that the
+        external build system (such as the Makefile, build-webkit, etc.)
+        defines the USE_NEW_BUILD_SYSTEM=YES build setting. This build setting
+        controls parts of our build instructions that are sensitive to when
+        XCBuild or the Legacy build system are being used. Notably, we need to
+        know when to use our custom “copy and modify” scripts with copying
+        certain header files (used with the Legacy build system) vs. using the
+        enhanced Copy Headers build phase that’s enabled with
+        APPLY_RULES_IN_COPY_HEADERS=YES (introduced with and used by XCBuild).
+        The choice of which method to copy headers is used is controlled by
+        USE_NEW_BUILD_SYSTEM.
+
+        There is no built-in build setting that we can probe to help us
+        determine which approach to take when copying and modifying headers,
+        which is why we need to define USE_NEW_BUILD_SYSTEM ourselves. But it
+        turns out that we can *detect* which build system is being used by
+        taking advantage of a subtle difference between the two systems. As
+        noted in:
+
+            https://developer.apple.com/documentation/xcode-release-notes/build-system-release-notes-for-xcode-10
+
+            “When an .xcconfig file contains multiple assignments of the same
+             build setting, later assignments using $(inherited) or
+             $(<setting_name>) will inherit from earlier assignments in the
+             .xcconfig. The legacy build system caused every use of
+             $(inherited) or $(<setting_name>) skip any other values defined
+             within the .xcconfig.”
+
+        This difference can be exploited as follows:
+
+            WK_WHICH_BUILD_SYSTEM = not_
+            WK_WHICH_BUILD_SYSTEM = $(inherited)legacy
+            WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM))
+            WK_USE_NEW_BUILD_SYSTEM_legacy = NO
+            WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES
+
+        We can then use WK_USE_NEW_BUILD_SYSTEM where we used to use the
+        externally-defined USE_NEW_BUILD_SYSTEM.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/JavaScriptCore.xcconfig:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+
 2020-08-12  Saam Barati  <[email protected]>
 
         Inline cache Replace and Setters on PureForwardingProxy

diff --git a/Source/JavaScriptCore/Configurations/Base.xcconfig b/Source/JavaScriptCore/Configurations/Base.xcconfig
@@ -215,3 +215,11 @@ WK_USER_LTO_MODE_thin = YES_THIN;
 WK_USER_LTO_MODE_none = NO;
 WK_USER_LTO_MODE_ = $(WK_DEFAULT_LTO_MODE);
 WK_DEFAULT_LTO_MODE = $(WK_USER_LTO_MODE_thin);
+
+// Use a difference in the way the Legacy build sytem and XCBuild interpret
+// xcconfig file to determine which is being used.
+WK_WHICH_BUILD_SYSTEM = not_
+WK_WHICH_BUILD_SYSTEM = $(inherited)legacy
+WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM))
+WK_USE_NEW_BUILD_SYSTEM_legacy = NO
+WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES
diff --git a/Source/JavaScriptCore/Configurations/JavaScriptCore.xcconfig b/Source/JavaScriptCore/Configurations/JavaScriptCore.xcconfig
@@ -51,9 +51,6 @@ PRODUCT_NAME = JavaScriptCore;
 PRODUCT_BUNDLE_IDENTIFIER = com.apple.$(PRODUCT_NAME:rfc1034identifier);
 
 INSTALLHDRS_SCRIPT_PHASE = YES;
-APPLY_RULES_IN_COPY_HEADERS = $(WK_APPLY_RULES_IN_COPY_HEADERS_$(USE_NEW_BUILD_SYSTEM));
-WK_APPLY_RULES_IN_COPY_HEADERS_ = NO;
-WK_APPLY_RULES_IN_COPY_HEADERS_NO = NO;
-WK_APPLY_RULES_IN_COPY_HEADERS_YES = YES;
+APPLY_RULES_IN_COPY_HEADERS = $(WK_USE_NEW_BUILD_SYSTEM);
 
 EXCLUDED_SOURCE_FILE_NAMES[sdk=iphone*] = framework.sb;
diff --git a/Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj b/Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
@@ -10924,7 +10924,7 @@
 			);
 			runOnlyForDeploymentPostprocessing = 0;
 			shellPath = /bin/sh;
-			shellScript = "if [ \"${XCODE_VERSION_ACTUAL}\" -ge \"1140\" -a \"${USE_NEW_BUILD_SYSTEM}\" = \"YES\" ]; then\n    # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.\n    exit 0\nfi\n\nexec ${SRCROOT}/postprocess-headers.sh\n";
+			shellScript = "if [ \"${XCODE_VERSION_ACTUAL}\" -ge \"1140\" -a \"${WK_USE_NEW_BUILD_SYSTEM}\" = \"YES\" ]; then\n    # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.\n    exit 0\nfi\n\nexec ${SRCROOT}/postprocess-headers.sh\n";
 		};
 		374F95C9205F9975002BF68F /* Make libWTF.a Symbolic Link */ = {
 			isa = PBXShellScriptBuildPhase;

diff --git a/Source/ThirdParty/ANGLE/ANGLE.xcodeproj/project.pbxproj b/Source/ThirdParty/ANGLE/ANGLE.xcodeproj/project.pbxproj
@@ -4289,7 +4289,7 @@
 			);
 			runOnlyForDeploymentPostprocessing = 0;
 			shellPath = /bin/sh;
-			shellScript = "if [ \"${XCODE_VERSION_ACTUAL}\" -ge \"1140\" -a \"${USE_NEW_BUILD_SYSTEM}\" = \"YES\" ]; then\n    # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.\n    exit 0\nfi\n\nexec \"$SRCROOT/adjust-angle-include-paths.sh\"\n";
+			shellScript = "if [ \"${XCODE_VERSION_ACTUAL}\" -ge \"1140\" -a \"${WK_USE_NEW_BUILD_SYSTEM}\" = \"YES\" ]; then\n    # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.\n    exit 0\nfi\n\nexec \"$SRCROOT/adjust-angle-include-paths.sh\"\n";
 		};
 /* End PBXShellScriptBuildPhase section */
 

diff --git a/Source/ThirdParty/ANGLE/ChangeLog b/Source/ThirdParty/ANGLE/ChangeLog
@@ -1,3 +1,54 @@
+2020-08-12  Keith Rollin  <[email protected]>
+
+        Remove the need for defining USE_NEW_BUILD_SYSTEM
+        https://bugs.webkit.org/show_bug.cgi?id=215439
+
+        Reviewed by Darin Adler.
+
+        When building WebKit for XCBuild, we currently require that the
+        external build system (such as the Makefile, build-webkit, etc.)
+        defines the USE_NEW_BUILD_SYSTEM=YES build setting. This build setting
+        controls parts of our build instructions that are sensitive to when
+        XCBuild or the Legacy build system are being used. Notably, we need to
+        know when to use our custom “copy and modify” scripts with copying
+        certain header files (used with the Legacy build system) vs. using the
+        enhanced Copy Headers build phase that’s enabled with
+        APPLY_RULES_IN_COPY_HEADERS=YES (introduced with and used by XCBuild).
+        The choice of which method to copy headers is used is controlled by
+        USE_NEW_BUILD_SYSTEM.
+
+        There is no built-in build setting that we can probe to help us
+        determine which approach to take when copying and modifying headers,
+        which is why we need to define USE_NEW_BUILD_SYSTEM ourselves. But it
+        turns out that we can *detect* which build system is being used by
+        taking advantage of a subtle difference between the two systems. As
+        noted in:
+
+            https://developer.apple.com/documentation/xcode-release-notes/build-system-release-notes-for-xcode-10
+
+            “When an .xcconfig file contains multiple assignments of the same
+             build setting, later assignments using $(inherited) or
+             $(<setting_name>) will inherit from earlier assignments in the
+             .xcconfig. The legacy build system caused every use of
+             $(inherited) or $(<setting_name>) skip any other values defined
+             within the .xcconfig.”
+
+        This difference can be exploited as follows:
+
+            WK_WHICH_BUILD_SYSTEM = not_
+            WK_WHICH_BUILD_SYSTEM = $(inherited)legacy
+            WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM))
+            WK_USE_NEW_BUILD_SYSTEM_legacy = NO
+            WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES
+
+        We can then use WK_USE_NEW_BUILD_SYSTEM where we used to use the
+        externally-defined USE_NEW_BUILD_SYSTEM.
+
+        * ANGLE.xcodeproj/project.pbxproj:
+        * Configurations/ANGLE-dynamic.xcconfig:
+        * Configurations/ANGLE-static.xcconfig:
+        * Configurations/Base.xcconfig:
+
 2020-08-07  Dean Jackson  <[email protected]>
 
         ANGLE: No need to check for Catalyst in the iOS build

diff --git a/Source/ThirdParty/ANGLE/Configurations/ANGLE-dynamic.xcconfig b/Source/ThirdParty/ANGLE/Configurations/ANGLE-dynamic.xcconfig
@@ -40,4 +40,4 @@ GCC_PREPROCESSOR_DEFINITIONS = $(DEBUG_DEFINES_$(CURRENT_VARIANT)) LIBGLESV2_IMP
 
 INSTALLHDRS_SCRIPT_PHASE = YES;
 USE_HEADERMAP = NO;
-APPLY_RULES_IN_COPY_HEADERS = $(USE_NEW_BUILD_SYSTEM);
+APPLY_RULES_IN_COPY_HEADERS = $(WK_USE_NEW_BUILD_SYSTEM);
diff --git a/Source/ThirdParty/ANGLE/Configurations/ANGLE-static.xcconfig b/Source/ThirdParty/ANGLE/Configurations/ANGLE-static.xcconfig
@@ -28,4 +28,4 @@ GCC_PREPROCESSOR_DEFINITIONS = $(DEBUG_DEFINES_$(CURRENT_VARIANT)) LIBGLESV2_IMP
 
 INSTALLHDRS_SCRIPT_PHASE = YES;
 USE_HEADERMAP = NO;
-APPLY_RULES_IN_COPY_HEADERS = $(USE_NEW_BUILD_SYSTEM);
+APPLY_RULES_IN_COPY_HEADERS = $(WK_USE_NEW_BUILD_SYSTEM);
diff --git a/Source/ThirdParty/ANGLE/Configurations/Base.xcconfig b/Source/ThirdParty/ANGLE/Configurations/Base.xcconfig
@@ -113,3 +113,11 @@ WK_USER_LTO_MODE_thin = YES_THIN;
 WK_USER_LTO_MODE_none = NO;
 WK_USER_LTO_MODE_ = $(WK_DEFAULT_LTO_MODE);
 WK_DEFAULT_LTO_MODE = $(WK_USER_LTO_MODE_thin);
+
+// Use a difference in the way the Legacy build sytem and XCBuild interpret
+// xcconfig file to determine which is being used.
+WK_WHICH_BUILD_SYSTEM = not_
+WK_WHICH_BUILD_SYSTEM = $(inherited)legacy
+WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM))
+WK_USE_NEW_BUILD_SYSTEM_legacy = NO
+WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES
diff --git a/Source/WebKit/ChangeLog b/Source/WebKit/ChangeLog
@@ -1,3 +1,55 @@
+2020-08-12  Keith Rollin  <[email protected]>
+
+        Remove the need for defining USE_NEW_BUILD_SYSTEM
+        https://bugs.webkit.org/show_bug.cgi?id=215439
+
+        Reviewed by Darin Adler.
+
+        When building WebKit for XCBuild, we currently require that the
+        external build system (such as the Makefile, build-webkit, etc.)
+        defines the USE_NEW_BUILD_SYSTEM=YES build setting. This build setting
+        controls parts of our build instructions that are sensitive to when
+        XCBuild or the Legacy build system are being used. Notably, we need to
+        know when to use our custom “copy and modify” scripts with copying
+        certain header files (used with the Legacy build system) vs. using the
+        enhanced Copy Headers build phase that’s enabled with
+        APPLY_RULES_IN_COPY_HEADERS=YES (introduced with and used by XCBuild).
+        The choice of which method to copy headers is used is controlled by
+        USE_NEW_BUILD_SYSTEM.
+
+        There is no built-in build setting that we can probe to help us
+        determine which approach to take when copying and modifying headers,
+        which is why we need to define USE_NEW_BUILD_SYSTEM ourselves. But it
+        turns out that we can *detect* which build system is being used by
+        taking advantage of a subtle difference between the two systems. As
+        noted in:
+
+            https://developer.apple.com/documentation/xcode-release-notes/build-system-release-notes-for-xcode-10
+
+            “When an .xcconfig file contains multiple assignments of the same
+             build setting, later assignments using $(inherited) or
+             $(<setting_name>) will inherit from earlier assignments in the
+             .xcconfig. The legacy build system caused every use of
+             $(inherited) or $(<setting_name>) skip any other values defined
+             within the .xcconfig.”
+
+        This difference can be exploited as follows:
+
+            WK_WHICH_BUILD_SYSTEM = not_
+            WK_WHICH_BUILD_SYSTEM = $(inherited)legacy
+            WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM))
+            WK_USE_NEW_BUILD_SYSTEM_legacy = NO
+            WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES
+
+        We can then use WK_USE_NEW_BUILD_SYSTEM where we used to use the
+        externally-defined USE_NEW_BUILD_SYSTEM.
+
+        No new tests -- no new or changed functionality.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/WebKit.xcconfig:
+        * WebKit.xcodeproj/project.pbxproj:
+
 2020-08-12  Alex Christensen  <[email protected]>
 
         Fail preconnect requests to deprecated TLS instead of allowing application to show warning

diff --git a/Source/WebKit/Configurations/Base.xcconfig b/Source/WebKit/Configurations/Base.xcconfig
@@ -187,3 +187,11 @@ WK_USER_LTO_MODE_thin = YES_THIN;
 WK_USER_LTO_MODE_none = NO;
 WK_USER_LTO_MODE_ = $(WK_DEFAULT_LTO_MODE);
 WK_DEFAULT_LTO_MODE = $(WK_USER_LTO_MODE_thin);
+
+// Use a difference in the way the Legacy build sytem and XCBuild interpret
+// xcconfig file to determine which is being used.
+WK_WHICH_BUILD_SYSTEM = not_
+WK_WHICH_BUILD_SYSTEM = $(inherited)legacy
+WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM))
+WK_USE_NEW_BUILD_SYSTEM_legacy = NO
+WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES
diff --git a/Source/WebKit/Configurations/WebKit.xcconfig b/Source/WebKit/Configurations/WebKit.xcconfig
@@ -161,10 +161,7 @@ EXCLUDED_SOURCE_FILE_NAMES = Resources/ios/*;
 EXCLUDED_SOURCE_FILE_NAMES[sdk=iphone*] = PluginProcessShim.dylib SecItemShim.dylib WebProcessShim.dylib *.pdf Resources/mac/* com.apple.WebKit.NetworkProcess.sb com.apple.WebKit.GPUProcess.sb com.apple.WebProcess.sb com.apple.WebKit.plugin-common.sb PlugInSandboxProfiles/*.sb;
 
 INSTALLHDRS_SCRIPT_PHASE = YES;
-APPLY_RULES_IN_COPY_HEADERS = $(WK_APPLY_RULES_IN_COPY_HEADERS_$(USE_NEW_BUILD_SYSTEM));
-WK_APPLY_RULES_IN_COPY_HEADERS_ = NO;
-WK_APPLY_RULES_IN_COPY_HEADERS_NO = NO;
-WK_APPLY_RULES_IN_COPY_HEADERS_YES = YES;
+APPLY_RULES_IN_COPY_HEADERS = $(WK_USE_NEW_BUILD_SYSTEM);
 
 WK_FRAMEWORK_HEADER_POSTPROCESSING_DISABLED[sdk=macosx*] = $(WK_FRAMEWORK_HEADER_POSTPROCESSING_DISABLED$(WK_MACOS_1016));
 WK_FRAMEWORK_HEADER_POSTPROCESSING_DISABLED_MACOS_BEFORE_1016 = YES;