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

[Alicia Boya García]

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.

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