[webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

Konstantin Tokarev annulen at yandex.ru
Tue Aug 29 14:00:47 PDT 2017

29.08.2017, 23:54, "Alicia Boya García" <aboya at igalia.com>:
> I'm all for stable bundle .cpp files. Automatic generation can be nice
> for the first time... and once in while we can try to modify the bundles
> to try to make the build even faster, but really most of the time bundle
> contents should not change unless new files are added and everybody
> should get the same bundles.
> If we're going to end up with some name collisions, we'd rather do so
> that every build of the same source tree gets collisions or no build
> gets them.
> The description of these .cpp bundles should become a project artifact,
> shared and versioned in the repository and treated carefully as such.

This is already the case for *AllInOne.cpp files of WebCore, which are enabled
by -DENABLE_ALLINONE_BUILD=ON option (--allinone-build in build-webkit).

> Also, in my earlier message about unified builds I explained how the
> distribution of the files within the bundles also affects the number of
> bundles that are rebuilt in response to changes in the source code. I
> also proposed that grouping together files implementing the same
> features could be a good start point to minimize the impact of this issue.
> On other note, I don't think namespacing static functions and variables
> as originally proposed is the way to go.
> The refactor would be ridiculously huge. Running `rg -w '^static' -tcpp
> --no-filename --no-heading |wc -l` in my local repository yields 16797
> instances of static functions and variables, only taking into account
> those where the word static is at the beginning of the line without any
> spaces before, which is a common case but not a requirement in C++. Note
> though that this regex excludes static class members as long as code is
> properly formatted (they would be indented); these are not included as
> they would not need any changes.
> static functions and variables in WebKit are used for hidden
> implementation details, which tend to very very specific and therefore
> receive long specific names with relatively little risk of collisions.
> Furthermore, collisions won't go unnoticed as in every case they will
> trigger a compilation error of the likes of 'redefinition of ‘int a’'.
> In this case the compiler will also show the inclusion stack mentioning
> the bundle file and the conflicting definition. The programmer will
> notice that both are static members in .cpp files, so the only way that
> error can arise is because they had a name collision due to unified
> source builds.
> We'd probably be better off handling the few collisions on a one by one
> basis, renaming the symbols or excluding the worst offenders from
> unified builds rather than plain out forbidding static declarations.
> -- Alicia
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


More information about the webkit-dev mailing list