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 <ysuz...@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 > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
