Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 587d0ed2988eaa5a58219beaa0d859046eec0115
https://github.com/WebKit/WebKit/commit/587d0ed2988eaa5a58219beaa0d859046eec0115
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-09-18 (Fri, 18 Sep 2026)
Changed paths:
M Tools/Scripts/build-webkit
M Tools/Scripts/set-webkit-configuration
M Tools/Scripts/webkitdirs.pm
M Tools/Scripts/webkitperl/webkitdirs_unittest/recordBuildSettings.pl
A
Tools/Scripts/webkitperl/webkitdirs_unittest/recordBuildSystemXcodeConfiguration.pl
M
Tools/SwiftBrowser/SwiftBrowser.xcodeproj/xcshareddata/xcschemes/SwiftBrowser.xcscheme
Log Message:
-----------
[cmake] Export cmake configuration as xconfig file usable by xcode
https://bugs.webkit.org/show_bug.cgi?id=323484
rdar://186711341
Reviewed by Elliott Williams.
Every script resolves the product directory through isCMakeBuild(), so they all
build above, and run against, the same WebKit. Xcode cannot be told any of this,
so a tool or an app built in Xcode above a WebKit built with CMake used the
Xcode
product directory, where that WebKit is not, and where nothing had built a
WebKit
at all it linked the SDK stub and ran on the shipping one.
build-webkit and set-webkit-configuration now publish where they put WebKit, as
WebKitBuild/BuildSystem.xcconfig, written whenever the build system resolves to
CMake and deleted whenever it resolves to Xcode. It publishes the base product
directory, the tree name, composed from EFFECTIVE_PLATFORM_NAME the way
cmakeCocoaTreeName() composes it, and the configuration this build produced,
which is ASan or TSan when a sanitizer is enabled. Nothing includes it. A build
above WebKit opts in from a LocalOverrides.xcconfig of its own, the way the file
itself describes, so a tree that never opts in is unaffected and the client
decides which WebKit it is built above.
To build a project of this checkout in Xcode above a WebKit built with CMake,
build WebKit, then create LocalOverrides.xcconfig next to WebKitBuild, which the
DebugRelease.xcconfig of every project here already includes when it exists:
#include? "WebKitBuild/BuildSystem.xcconfig"
FRAMEWORK_SEARCH_PATHS = $(inherited) $(WK_CMAKE_CONFIGURATION_BUILD_DIR)
The first line reads what build-webkit recorded, so the platform, configuration
and sanitizer follow the WebKit that was built, and the same two lines serve
every platform. The second searches that directory for the frameworks the
project
links and imports, ahead of the SDK. The project itself keeps building into the
Xcode product directory. Delete the file to build against the SDK again. It is a
build configuration rather than a scheme or a workspace setting, so it applies
to
Xcode and to the command line alike.
Fly-By: only re-write the sticky build configuration file if its content
changed.
BuildSystem.xcconfig follows the same condition as XCode has been known to
crash or hang if a config file it is using got modified
* Tools/Scripts/build-webkit: Publish where this build put WebKit, alongside
recording the settings it was given.
* Tools/Scripts/set-webkit-configuration: Ditto, and delete what was published
on --reset.
* Tools/Scripts/webkitdirs.pm:
(writeFileIfChanged):
(writeBuildSetting):
(recordBuildSystemXcodeConfiguration): Added.
* Tools/Scripts/webkitperl/webkitdirs_unittest/recordBuildSettings.pl:
*
Tools/Scripts/webkitperl/webkitdirs_unittest/recordBuildSystemXcodeConfiguration.pl:
Added.
(configurationContents):
(publishedConfiguration):
(modificationTime):
*
Tools/SwiftBrowser/SwiftBrowser.xcodeproj/xcshareddata/xcschemes/SwiftBrowser.xcscheme:
Stop looking for implicit dependencies, as every other tool scheme already does.
WebKit is not built alongside SwiftBrowser, it is taken from wherever the build
system left it.
Canonical link: https://commits.webkit.org/321374@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
