Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: a5f61994499a9a688bd4fe13c8abf6666cc98fac
https://github.com/WebKit/WebKit/commit/a5f61994499a9a688bd4fe13c8abf6666cc98fac
Author: Simon Lewis <[email protected]>
Date: 2026-04-22 (Wed, 22 Apr 2026)
Changed paths:
M Source/WebKit/PlatformMac.cmake
M Source/cmake/OptionsMac.cmake
A Tools/Scripts/generate-cmake-xcode-project
Log Message:
-----------
[CMake] Add generate-cmake-xcode-project for debugging the Mac CMake build in
Xcode
https://bugs.webkit.org/show_bug.cgi?id=312543
Reviewed by Pascoe.
Add a generator that wraps a CMake/Ninja build directory in a thin Xcode
project so the ninja-built products can be launched and debugged with
Xcode's lldb UI (breakpoints, variable inspector, view debugger, memory
graph) while ninja remains the build system.
The generated project contains a single PBXLegacyTarget that invokes
ninja through a hermetic wrapper script. The wrapper scrubs Xcode's
injected environment (SDKROOT, ARCHS, MACOSX_DEPLOYMENT_TARGET, CC/CXX,
TOOLCHAINS, ...) and re-establishes SDKROOT from the -isysroot value
baked into build.ninja, so a CMake reconfigure triggered from inside
Xcode produces a build.ninja identical to one produced from a terminal,
and existing object files and ccache entries remain valid.
One scheme is generated per Mach-O executable / .app bundle discovered
in the build directory. App-bundle schemes set DYLD_FRAMEWORK_PATH and
__XPC_DYLD_FRAMEWORK_PATH (matching run-minibrowser) so XPC service
children load the just-built WebKit.framework; plain-executable schemes
set neither and rely on LC_RPATH, which avoids redirecting Xcode's
injected liblldbViewDebuggerSupport.dylib at the build's WebKit. All
schemes reference an lldbinit that inverts the build's -fdebug-prefix-map
and loads Tools/lldb/lldb_webkit.py.
Folder references for Source/, Tools/, and each <framework>/DerivedSources
in the build directory populate the Project Navigator and Quick Open.
MiniBrowser is pinned as the default scheme via xcschememanagement.plist.
Also make the CMake-built WebKit.framework re-export WebKitLegacy and
libobjc, matching REEXPORTED_FRAMEWORK_NAMES / REEXPORTED_LIBRARY_NAMES
in WebKit.xcconfig. Without this, clients that link WebKit expecting WK1
symbols (e.g. Xcode's view-debugger support dylib, which imports
_OBJC_CLASS_$_WebView) abort at load when DYLD_FRAMEWORK_PATH points at
a CMake build. WebKitLegacy is removed from WebKit_PRIVATE_LIBRARIES and
linked solely via -reexport_library, since ld64 resolves a dylib's
load-command type by its last reference and a plain target_link_libraries
entry would downgrade the LC_REEXPORT_DYLIB to LC_LOAD_DYLIB.
Usage:
cmake --preset mac-dev-release
ninja -C WebKitBuild/cmake-mac/Release
Tools/Scripts/generate-cmake-xcode-project WebKitBuild/cmake-mac/Release
open WebKitBuild/cmake-mac/Release/WebKit.xcodeproj
# Select the MiniBrowser scheme, Cmd-R.
The project is also regenerated on every cmake configure via an
execute_process hook in OptionsMac.cmake; the explicit invocation above
is needed once after the first build so that schemes (which are
discovered from built executables) are populated.
* Source/WebKit/PlatformMac.cmake:
* Source/cmake/OptionsMac.cmake:
* Tools/Scripts/generate-cmake-xcode-project: Added.
Canonical link: https://commits.webkit.org/311783@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
