Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 050a60948e62dcc9d9a0c4c6028235b889aece75
https://github.com/WebKit/WebKit/commit/050a60948e62dcc9d9a0c4c6028235b889aece75
Author: Zak Ridouh <[email protected]>
Date: 2026-07-31 (Fri, 31 Jul 2026)
Changed paths:
M Source/cmake/WebKitMacros.cmake
Log Message:
-----------
[CMake] Don't gate compiles on dependency framework code signing
https://bugs.webkit.org/show_bug.cgi?id=320682
rdar://183667606
Reviewed by Elliott Williams.
_WEBKIT_TARGET_INTERFACE attached ${_target}_CodeSign to the interface
library that every consumer links. CMake cannot know what a utility target
produces, so it conservatively makes each one in a consumer's dependency
closure an order-only dependency of every one of that consumer's object
files. Nothing in WebCore compiled until JavaScriptCore had linked and been
signed, nothing in WebKit until WebCore and WebKitLegacy had, and so on;
JavaScriptCore_CodeSign alone gated 877 compile edges, 51% of the build's
compile work.
Depend on the code signing stamp file instead, via INTERFACE_LINK_DEPENDS.
Compiling against a framework needs its staged headers and module maps,
which ${_target}_INTERFACE_DEPENDENCIES already orders; only linking reads
the binary that `codesign --force` rewrites in place. Depending on the stamp
also keeps signing ordered ahead of a directly built target, which the
ALL-ness of ${_target}_CodeSign did not guarantee. Executables sign in a
POST_BUILD command and have no stamp, so they keep the existing target-level
dependency.
39 of 82 cmake_object_order_depends_target_* phonies carried a *_CodeSign
dependency before, 0 after; on iOS, 29 of 79 before, 0 after.
* Source/cmake/WebKitMacros.cmake:
Canonical link: https://commits.webkit.org/318344@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
