Michael states his desired benefit of the original proposal as:

...

...

...so we can keep track of it. Not knowing about bundled sources causes various problems, e.g. we've previously shipped unused libavif and dav1d sources in WebCore due to not knowing about them.

I see an additional benefit that it makes searching the code more straightforward. I currently have to exclude a bunch of directories when doing search and replace, for instance, and having a single consistent rule would make that easier. From the additional proposals I provide below, #1 just extends that convenience even further, making the rule dead simple. For #2, I see a hopeful benefit in reducing checkout size and build times (One could argue that these third party drops change infrequently, so I shouldn’t effect really effect build time in the aggregate, but I have found despite our best intentions, I trash my build repo for one reason or another more often than I would like). - Sam

On Oct 2, 2024, at 6:58 PM, Yusuke Suzuki <ysuzuki@apple.com> wrote:

The question I have is, what is the benefit from this policy change?

-Yusuke

...

On Oct 1, 2024, at 7:41 AM, Sam Weinig via webkit-dev <webkit-dev@lists.webkit.org> wrote:

I think this makes a lot of sense and we should adopt this into the style guidelines.

Two additional steps I am curious if we can take are:

1. Moving all, including source currently in WTF and PAL to Sources/ThirdParty.

Having a single place seems more straightforward than multiple. Are there technical reasons this can’t be done? Are there non-technical reasons it shouldn’t be done?

2. Moving to an out-of-tree model for third party code.

Ideally, we wouldn’t need to have copies of the third party code in the WebKit repository at all, and instead embed a dependency that can be resolved before building (downloading the appropriate remote repository versions, applying any additional changes, etc.)

This would obviously be a bigger lift, but has potentially nice properties like being able to use pre-built binaries for infrequently changing third party code where available.

Are there technical / non-technical reasons (other than the obvious effort it would require) why this would be a problem?

- Sam

...

On Sep 25, 2024, at 11:41 AM, Michael Catanzaro via webkit-dev <webkit-dev@lists.webkit.org> wrote:

Hi developers,

I request that bundled or "vendored" sources copied from other upstream projects should live under a directory named "ThirdParty" so we can keep track of it. Not knowing about bundled sources causes various problems, e.g. we've previously shipped unused libavif and dav1d sources in WebCore due to not knowing about them.

Ideally third-party code should be placed in Source/ThirdParty. If the requirements of Apple's internal build system do not allow for putting the code in Source/ThirdParty, then you can create a new ThirdParty directory wherever needed, e.g. Source/WebCore/PAL/ThirdParty.

Currently we have at least wtf/simde and wtf/simdutf violating these guidelines. If somebody with XCode could please create a wtf/ThirdParty and move the directories to there, that would be helpful. Unfortunately it's not easy to move sources without XCode. If you know of other bundled sources elsewhere in WebKit, let's do the similar moves for those as well.

(This rule doesn't need to apply for minimal one-time copying, like taking just a useful file or two from an upstream project and incorporating it into WebKit. Of course that is fine. We just shouldn't have entire upstream projects hidden in WebKit.)

Thanks,

Michael

_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev