I'm in favor of a non-Unified EWS builder. It seems it would largely prevent the current situation where I have to add random headers to make my patch build, usually after the patch has been reviewed and revised. This "surprise, someone forgot a header" situation has no effect on our production builds, but it does affect engineering velocity quite a bit when multiple patches are being juggled.
Just as it's easier to fix style checker problems before committing, it's easier to address missing includes before committing. And I am not aware of a better way to improve the situation, other than to add some basic pre-commit checks. Given that there is some disagreement as to whether this is even a problem at all, perhaps we could try it out for a while. Diego, do you have the resources to set up an EWS bot in this configuration? BJ Burg (they/them) > On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev > <webkit-dev@lists.webkit.org> wrote: > > Hi everyone, > > In Igalia we have been discussing the need of deploying a new builder > which builds WebKit using non-unified sources, and we know that at least > the folks at Sony are also in favor. > > One side effect of Unified Source building is that it hides compilation > errors. The kinds of errors that usually get hidden by unified builds > are missing headers inclusions and missing definitions of functions > declared inline; the latter being tricky to debug because it results in > mysterious linker errors. This is caused by unified builds stashing > several .cpp files together for compilation, so the definitions and > header inclusions done in one “leak” into the others. As for missing > header inclusion errors, a source file might include a header definition > as a co-lateral effect of being stashed together with another file that > indeed includes the missing header. > > These hidden compilation errors may arise later at some point if unified > source files are stashed together in a different manner. > > The current situation is requiring periodical maintenance. You can check > build fixes commits due to unified source compilation with: > > $ git log --pretty=short --grep "Non-unified" > > Here are some examples: > https://bugs.webkit.org/show_bug.cgi?id=222652 > https://bugs.webkit.org/show_bug.cgi?id=222755 > https://bugs.webkit.org/show_bug.cgi?id=221701 > > A new builder which builds WebKit with non-unified Source will highly > help to improve this situation. Compilation errors will be detected as > soon as possible and will save a lot of time not only for the developers > who are currently doing this manual maintenance but for anyone who would > like to build WebKit, and may stumble on compilation errors accidentally > introduced due to unified sources. > > While correct compilation of the codebase can only be guaranteed with > non-unified source builds, we do not propose switching the current EWS > compilation builders to non-unified because it's slower and the EWS > LayoutTests and API test bots use the products built by the EWS builders > — we do not want to delay getting results from those. That's why we are > proposing a new builder: it will run on parallel, resulting in no > slowdown for the other EWS builders, which will keep using unified > builds. > > How this new builder will impact developers? The EWS LayoutTest bots > take at least 1 hour to complete a build. We think that as long as this > new EWS Non-Unified builder is within that time budget, this new EWS > wont' slow down development speed. > > Thoughts? > > Best regards, > > Diego > _______________________________________________ > 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