Make WebGPU.xcodeproj and WebGPU.framework
Created attachment 441044 [details] WIP
Comment on attachment 441044 [details] WIP View in context: https://bugs.webkit.org/attachment.cgi?id=441044&action=review > Source/WebGPU/ChangeLog:9 > + without requiring all of WebKit. This patch creates a new Xcode project Is there a particular benefit of having a separate project, not just a target? Managing these adds substantial overhead.
Comment on attachment 441044 [details] WIP View in context: https://bugs.webkit.org/attachment.cgi?id=441044&action=review >> Source/WebGPU/ChangeLog:9 >> + without requiring all of WebKit. This patch creates a new Xcode project > > Is there a particular benefit of having a separate project, not just a target? Managing these adds substantial overhead. I don't know! If a separate team wanted to use the WebGPU implementation, but it was a new target (actually probably 2 new targets - WebGPU & WGSL), presumably inside WebCore.xcodeproj, what would that workflow look like? Right now, we have PAL.xcodeproj as a child of WebCore.xcodeproj. Would that have the same substantial overhead? Is your concern just about the addition of a .xcodeproj file, or is it also about creating a new .framework at build time?
Comment on attachment 441044 [details] WIP View in context: https://bugs.webkit.org/attachment.cgi?id=441044&action=review >>> Source/WebGPU/ChangeLog:9 >>> + without requiring all of WebKit. This patch creates a new Xcode project >> >> Is there a particular benefit of having a separate project, not just a target? Managing these adds substantial overhead. > > I don't know! > > If a separate team wanted to use the WebGPU implementation, but it was a new target (actually probably 2 new targets - WebGPU & WGSL), presumably inside WebCore.xcodeproj, what would that workflow look like? > > Right now, we have PAL.xcodeproj as a child of WebCore.xcodeproj. Would that have the same substantial overhead? > > Is your concern just about the addition of a .xcodeproj file, or is it also about creating a new .framework at build time? s/Would that have the same substantial overhead?/Would moving a new .xcodeproj to become a child of WebCore.xcodeproj instead of a sibling have the same substantial overhead?/
Following up directly.
Created attachment 441271 [details] WIP
Created attachment 441287 [details] Standalone .xcodeproj
Created attachment 441420 [details] Patch
Created attachment 441424 [details] WebCore targets
Comment on attachment 441424 [details] WebCore targets View in context: https://bugs.webkit.org/attachment.cgi?id=441424&action=review > Source/WebCore/ChangeLog:13 > + We've gotten some requests to be able to use WebGPU from native code, > + without requiring all of WebKit. This patch adds two new targets to > + WebCore.xcodeproj: one that builds the WGSL compiler, and one that > + builds WebGPU.framework. The WGSL compiler is built as a static library > + that is only used by WebGPU.framework. This patch implements one dummy > + function in both targets. I think this might be better in Source/ rather than in Source/WebCore/? What do you think?
(In reply to Alexey Proskuryakov from comment #2) > Comment on attachment 441044 [details] > WIP > > View in context: > https://bugs.webkit.org/attachment.cgi?id=441044&action=review > > > Source/WebGPU/ChangeLog:9 > > + without requiring all of WebKit. This patch creates a new Xcode project > > Is there a particular benefit of having a separate project, not just a > target? Managing these adds substantial overhead. Having separate projects makes it much clearer what the lines of abstraction are and what is a layering violation.
(In reply to Sam Weinig from comment #11) > (In reply to Alexey Proskuryakov from comment #2) > > Comment on attachment 441044 [details] > > WIP > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=441044&action=review > > > > > Source/WebGPU/ChangeLog:9 > > > + without requiring all of WebKit. This patch creates a new Xcode project > > > > Is there a particular benefit of having a separate project, not just a > > target? Managing these adds substantial overhead. > > Having separate projects makes it much clearer what the lines of abstraction > are and what is a layering violation. [To anyone following along, I'm following-up with Sam offline, since there are considerations here regarding Apple's internal build systems.]
Comment on attachment 441287 [details] Standalone .xcodeproj View in context: https://bugs.webkit.org/attachment.cgi?id=441287&action=review > Source/WebGPU/Configurations/WebGPU.xcconfig:30 > +INSTALL_PATH = $(INSTALL_PATH_$(WK_COCOA_TOUCH)); > +INSTALL_PATH_cocoatouch = $(WK_ALTERNATE_WEBKIT_SDK_PATH)$(SYSTEM_LIBRARY_DIR)/PrivateFrameworks; > +INSTALL_PATH_ = $(WEBGPU_FRAMEWORKS_DIR); This is wrong. It shouldn't be installed inside WebKit.framework.
Comment on attachment 441424 [details] WebCore targets View in context: https://bugs.webkit.org/attachment.cgi?id=441424&action=review > Source/WebCore/Configurations/WebCore.xcconfig:65 > +NORMAL_WEBKIT_FRAMEWORKS_DIR = $(WK_ALTERNATE_WEBKIT_SDK_PATH)$(SYSTEM_LIBRARY_DIR)/Frameworks; > + > +WEBKIT_FRAMEWORKS_DIR = $(WEBKIT_FRAMEWORKS_DIR_USE_OVERRIDE_FRAMEWORKS_DIR_$(WK_USE_OVERRIDE_FRAMEWORKS_DIR)); > +WEBKIT_FRAMEWORKS_DIR_USE_OVERRIDE_FRAMEWORKS_DIR_NO = $(NORMAL_WEBKIT_FRAMEWORKS_DIR); > +WEBKIT_FRAMEWORKS_DIR_USE_OVERRIDE_FRAMEWORKS_DIR_YES = $(WK_OVERRIDE_FRAMEWORKS_DIR); > + > +INSTALL_PATH = $(WEBKIT_FRAMEWORKS_DIR); Whoops
Created attachment 441686 [details] Patch
Created attachment 441694 [details] Patch
Comment on attachment 441694 [details] Patch rs=me
Created attachment 441784 [details] Patch for committing
Created attachment 441789 [details] Patch for committing
Created attachment 441791 [details] Patch for committing
<rdar://problem/84452606>
Comment on attachment 441791 [details] Patch for committing View in context: https://bugs.webkit.org/attachment.cgi?id=441791&action=review > Source/WebGPU/WebGPU/WebGPUObjC.mm:33 > + id<MTLDevice> device = MTLCreateSystemDefaultDevice(); https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/configure-xcode-for-embedded-development#L329 😅
Committed r285480 (244004@main): <https://commits.webkit.org/244004@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 441791 [details].