[webkit-dev] New EWS Non-Unified builder
weinig at apple.com
Mon May 3 12:21:57 PDT 2021
I am curious about the current state of our knowledge about the various benefits we are gaining from Unified Source. I think it is important to reevaluate it from time to time to ensure we are still getting the benefits we want (as there are some not so insignificant downsides). I know when it was introduced, it was a win for clean builds but I don’t believe there have been any recent measurements.
So, does anyone have any recent measurements of clean build times with and without unified sources enabled? If so, what is the current delta?
> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev <webkit-dev at 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:
> 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
> 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.
> Best regards,
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev