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

[Keith Miller]

As far as the static renaming problem, Darin convinced me in the other thread that we probably don’t need such a heavy handed approach. At least in JSC, there are a number of variables that have generic names that should be put into a namespace but the majority probably don’t need to be renamed. I’ll gather some stats on name collisions and report back soon. Since my proposal will only bundle files by directory, we could mitigate global name collisions by having a bot build with each file fully unified. As Saam mentioned before, we should probably also have a bot that runs without unified source builds so we don’t end up relying on includes from other .cpp files.

I’m not convinced statically bundling is the right approach. By automatically, choosing the bundles we don’t require contributors to understand the intricacies of how we should load balance our unified source build system. New files are quite common and ensuring that people bundle their new files in a reasonable manner seems like it would need to be a continual effort, which I don’t want to volunteer to do. We could make a script that does this but then why not just run that script all the time? There are also likely to be a huge number of bundles, for JSC there are ~120 so would that mean there are 120 checked in unified source files? If not, then I assume the list will be parsed by a script and files would be emitted it seems like that script might as well automatically decide how to bundle those files. As I described above, I think the bot solution should prevent people getting build errors that are not reproducible when the add a new file. 

The automated system should handle your concern about bundling similar .cpp files together. The proposed system bundles by directory and also sorts the files in those directories when dividing up the files. Is there any reason to think that we would not do roughly the same thing if we were bundling by hand?

Cheers,
Keith

> On Aug 29, 2017, at 1:53 PM, Alicia Boya García <aboya at igalia.com> wrote:
> 
> 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