The value of macro define WTF_USE_APPLE_INTERNAL_SDK may disagree with the value of Xcode configuration variable USE_INTERNAL_SDK (i.e. WTF_USE_APPLE_INTERNAL_SDK != USE_INTERNAL_SDK). We should ensure that WTF_USE_APPLE_INTERNAL_SDK == USE_INTERNAL_SDK.
Some comments on the definitions and use of the associated variables:
*** HAVE_INTERNAL_SDK - defined in Internal/Configurations/HaveInternalSDK.xcconfig. Used in the various Base.xcconfig files to define USE_INTERNAL_SDK:
USE_INTERNAL_SDK = $(USE_INTERNAL_SDK_$(CONFIGURATION));
USE_INTERNAL_SDK_Production = YES;
USE_INTERNAL_SDK_Debug = $(HAVE_INTERNAL_SDK);
USE_INTERNAL_SDK_Release = $(HAVE_INTERNAL_SDK);
*** USE_INTERNAL_SDK - Defined as above. Used in xcconfig files to select SDK (Q: How does this relate to ios-family SDKs?):
SDKROOT = $(SDKROOT_$(USE_INTERNAL_SDK));
SDKROOT_ = macosx;
SDKROOT_YES = macosx.internal;
Also used to control if generate-xcfilelists is executed, and to determine if there are xcfilelists additions in Internal.
Also controls existance of features in FeatureDefines.xcconfig.
*** USE_APPLE_INTERNAL_SDK - defined in WTF/wtf/Platform.h if CoreFoundation/CFPriv.h exists. Checked when running IDL generator and when post-processing headers. Checked a lot in *SPI.h headers. Checked in some implementation files.
Given all of the above, I think that the following change should satisfy Dan’s request. Basically, if USE_INTERNAL_SDK is defined in the .xcconfig file, then use that to initialize USE_APPLE_INTERNAL_SDK in the C/C++ sources. Otherwise, fallback to the previous method of initializing it.
+#define USE_APPLE_INTERNAL_SDK USE_INTERNAL_SDK
#if defined __has_include && __has_include(<CoreFoundation/CFPriv.h>)
#define USE_APPLE_INTERNAL_SDK 1
One might make the argument that we should just get rid of the old method and just use:
#define USE_APPLE_INTERNAL_SDK USE_INTERNAL_SDK
However, this shorter version makes one outstanding issue worse: In WebCore/DerivedSources.make, Platform.h is compiled outside of Xcode. This means that the xcconfig files are not brought into play, and there’s no definition for USE_INTERNAL_SDK at all. In turn, USE_APPLE_INTERNAL_SDK is not defined, and so the IDL files might not get get generated correctly. To support that scenario, we need to make some sort of check in order to provide a sane definition of USE_APPLE_INTERNAL_SDK. Therefore, let’s keep the __has_include check as the fallback.
Dan does this cover your scenario where "[USE_APPLE_INTERNAL_SDK] may disagree with ... USE_INTERNAL_SDK"?