Bug 231661 – Make WebGPU.xcodeproj and WebGPU.framework

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGPU

[Myles C. Maxfield]

Make WebGPU.xcodeproj and WebGPU.framework

[Myles C. Maxfield]

Created attachment 441044 [details]
WIP

[Alexey Proskuryakov]

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.

[Myles C. Maxfield]

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?

[Myles C. Maxfield]

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?/

[Alexey Proskuryakov]

Following up directly.

[Myles C. Maxfield]

Created attachment 441271 [details]
WIP

[Myles C. Maxfield]

Created attachment 441287 [details]
Standalone .xcodeproj

[Myles C. Maxfield]

Created attachment 441420 [details]
Patch

[Myles C. Maxfield]

Created attachment 441424 [details]
WebCore targets

[Sam Weinig]

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?

[Sam Weinig]

(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.

[Myles C. Maxfield]

(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.]

[Myles C. Maxfield]

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.

[Myles C. Maxfield]

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

[Myles C. Maxfield]

Created attachment 441686 [details]
Patch

[Myles C. Maxfield]

Created attachment 441694 [details]
Patch

[Dean Jackson]

Comment on attachment 441694 [details]
Patch

rs=me

[Myles C. Maxfield]

Created attachment 441784 [details]
Patch for committing

[Myles C. Maxfield]

Created attachment 441789 [details]
Patch for committing

[Myles C. Maxfield]

Created attachment 441791 [details]
Patch for committing

[Radar WebKit Bug Importer]

<rdar://problem/84452606>

[Myles C. Maxfield]

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 😅

[EWS]

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].