Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 484abf80fd1d0492650cf766d5b8aea16b6f755f
https://github.com/WebKit/WebKit/commit/484abf80fd1d0492650cf766d5b8aea16b6f755f
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
M Source/WebKit/PlatformCocoa.cmake
M Source/cmake/WebKitMacros.cmake
M Source/cmake/WebKitSwiftPrewarm.cmake
A Tools/Scripts/swift/depfile.py
A Tools/Scripts/swift/rebuild_trigger.py
A Tools/Scripts/swift/rebuild_trigger_unittest.py
M Tools/Scripts/swift/swiftc-wrapper.py
M Tools/gtk/manifest.txt.in
M Tools/wpe/manifest.txt.in
Log Message:
-----------
[CMake] Two consecutive builds are not a no-op: the Swift modules recompile
in the second
https://bugs.webkit.org/show_bug.cgi?id=324136
rdar://187351520
Reviewed by Adrian Taylor.
Four defects kept the graph dirty for a build after the build that settled it.
1) The edge producing <target>_SwiftRebuildTrigger.swift takes
<target>.swift-deps.d as an input and touched the trigger unconditionally. The
trigger is a source of the Swift module and swiftc-wrapper.py writes that
depfile after the module compiles, so the depfile was left newer than the
trigger and the next build recompiled WebKit's, PAL's and WebGPU's Swift
modules. The depfile has to stay an input: ninja ingests one only by running the
edge that declares it.
2) The merged depfile listed its dependencies in the order swiftc's frontend
jobs reported them, which follows job scheduling. Two compiles of the same
sources could produce the same dependency set in a different order, rewrite the
file, and cost a build.
3) WEBKIT_ADD_SWIFT_PREWARM copies the consumer's COMPILE_OPTIONS and filtered
out two flags, so SwiftPrewarmMac inherited WebKit's
--emit-ninja-depfile and --ninja-depfile-target and wrote WebKit's dependency
file with its own dependencies. The prewarm is ordered ahead of WebKit's
compile,
so WebKit's own write followed and restored the list; the round trip rewrote the
file, and cost a build, on every build where both compiled.
4) Both commands that stage WebKit.swiftmodule into WebKit.framework said
DEPENDS WebKit, which CMake turns into a file dependency on the framework
binary. Code signing rewrites that binary after the staging has run.
For 1), rebuild_trigger.py performs the touch, and only when an input has
changed since the module last compiled. That moment is a stamp
swiftc-wrapper.py writes, not the trigger's own mtime: the trigger edge runs
early in a build, ahead of the several hundred generated headers the module
imports, and swiftc leaves most of its outputs' mtimes alone when their contents
do not change. The edge already carries restat = 1, so ninja treats the module
as clean on a run that only ingests the depfile. For 2), the merged list is
sorted. For 3), the depfile and stamp options join the prewarm's filter. For 4),
the staging commands depend on the swiftmodule they copy and keep their ordering
behind WebKit through add_dependencies.
Rewriting the depfile still costs one build, so swiftc-wrapper.py reports what
changed when it rewrites, and a build that is not a no-op says why. The
Makefile-syntax depfile parsing moves to Tools/Scripts/swift/depfile.py, shared
with swiftc-wrapper.py, and handles the `target:` spelling of the merged depfile
as well as swiftc's `target : deps`.
* Source/WebKit/PlatformCocoa.cmake:
* Source/cmake/WebKitMacros.cmake:
* Source/cmake/WebKitSwiftPrewarm.cmake:
* Tools/Scripts/swift/depfile.py: Added.
* Tools/Scripts/swift/rebuild_trigger.py: Added.
* Tools/Scripts/swift/rebuild_trigger_unittest.py: Added.
* Tools/Scripts/swift/swiftc-wrapper.py:
* Tools/gtk/manifest.txt.in:
* Tools/wpe/manifest.txt.in:
Canonical link: https://commits.webkit.org/321215@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
