On Thu, Apr 29, 2021 at 9:18 PM Darin Adler via webkit-dev < webkit-dev@lists.webkit.org> wrote:
> > On Apr 29, 2021, at 9:06 PM, Tim Horton via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > > > > it is definitely highly annoying > > It’s possible that where my thinking differs from others on this is that I > don’t think shifting annoying work from one set of commits (the ones adding > a new file) to a different set (the ones unknowingly adding need for a new > include for non-unified builds) is a significant improvement. Adding more > EWS bubbles has a cost. > One key benefit of keeping non-unified builds working is that it would make build brokerage more predictable. Today, when you're adding, removing, or renaming an existing new file, it may compile just fine on the particular port / platform you're using locally yet can still cause a build failure in other ports / platforms since different ports / platforms almost always compile a different set of translation units. If we kept unified builds always working, then the build failure will happen more consistently, making it easier to detect before uploading a patch instead of after observing EWS failures or worse after landing commits because EWS didn't have coverage. Every time someone new starts working on the WebKit project, the topic of mysterious build failures caused by the unified build system comes up as a topic. It's yet another random thing a new developer would have to learn. Anything we can do to reduce the total amount of random knowledge someone has to have to have to be productive in the WebKit project is a positive change in my opinion. - R. Niwa
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
