Bug 312033 – [CMake] Mirror PlatformEnableCocoa.h derived features in Mac CMake build

• Status: NEW
• Component: CMake

[[e-mail]]

IDL/CSS codegen only sees CMake FEATURE_DEFINES_WITH_SPACE_SEPARATOR, not preprocessor values from PlatformEnableCocoa.h. When they disagree, generated bindings have variant type mismatches. Currently ~25 flags are manually mirrored in OptionsMac.cmake.

[[e-mail]]

some notes about this one:

The root cause of the CMake/Xcode divergence is the #if !defined() guard pattern in PlatformEnableCocoa.h.

When a feature is registered in WebKitFeatures.cmake, it gets written to cmakeconfig.h (included before Platform.h). If OptionsMac.cmake doesn't explicitly set it ON, cmakeconfig.h emits #define ENABLE_X 0. This poisons the #if !defined(ENABLE_X) guard in PlatformEnableCocoa.h, making that header's value dead code.

Features that are ONLY in PlatformEnableCocoa.h (~200+, never registered in WebKitFeatures.cmake) work correctly -- the !defined() guard fires and the header drives the value. The problem is exclusively features that exist in both places.

This affects more than IDL/CSS codegen. The UnifiedWebPreferences.yaml pipeline emits #if ENABLE(X) guards verbatim in all generated preference files. When cmake's ENABLE flags disagree with what Xcode would set, entire preference blocks get #if-0'd out. The generated files are textually identical to Xcode's, but compile to different code.

Currently confirmed divergences: ENABLE_WEBGPU (bug 312031), ENABLE_WEB_CODECS, ENABLE_WEBDRIVER_BIDI. Each is enabled by PlatformEnableCocoa.h for Mac but defaults OFF in WebKitFeatures.cmake with no OptionsMac.cmake override.

Possible fix approaches:
(A) Don't register Cocoa-handled features in WebKitFeatures.cmake (let headers drive them). Breaks cross-platform feature queries in cmake.
(B) Add a CI script that diffs WebKitFeatures.cmake defaults against PlatformEnableCocoa.h outcomes and flags divergences.
(C) Keep manually mirroring in OptionsMac.cmake (current approach, known to drift silently).