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