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

[Michael Catanzaro]

On Mon, Aug 28, 2017 at 7:37 PM, Keith Miller <keith_miller at apple.com> 
wrote:
> Given that most of the build time in incremental builds is scanning 
> dependencies, this change is probably only barely noticeable.

What, with CMake? That's true of the make backend, but definitely not 
the ninja backend. You should pass -GNinja to get the ninja generator. 
I thought the build-webkit script already did this by default.

> Bundling happens as part of the CMake configuration process, in the 
> CMake build.

Do you have a patch or branch somewhere we could look at? This is very 
exciting!

> namespace FILENAME {
> 	static int myVariable { 0 };
> 	static int myFunction() { return myVariable; }
> }

I'm afraid you might be underestimating how much pain this would be. We 
use file-static functions all over the place, scattered across source 
files. We can't reasonably add namespace guards around individual 
functions scattered all throughout files, so we're going to need to 
move them all to one place, in the files, which will seriously hurt 
readability. Regardless, we will need a lot of forward declarations to 
make this workable. (At least those can all go in one place.)

I'm not saying this is a bad idea. I think we should try it. We should 
be willing to put up with some annoyance in order to get faster builds. 
But I suspect converting the WebCore and WebKit layers is going to be a 
lot harder than JSC.

Wherever possible, we are going to want to convert file-static 
functions into private C++ class member functions. That will go a long 
way to easing the pain in C++ files, and it will probably be a lot of 
work, but it seems like a no-brainer task if we're going to be using 
unified builds. GObject implementations are going to be harder though, 
since that won't be an option. But it would be simple to just exclude 
those; they're probably a very small component of overall build time. 
And I have no idea how this will work with Objective C++, but those 
could be excluded too if need be.

Some alternative strawman proposals:

 * We could not use any namespaces and just fix name clashes as they 
arise, but only if we have some more predictable way to determine which 
files will be built together regardless of port or build configuration. 
Say files in small directories all get built together, while files in 
large directories get built together if their filenames start with the 
same letter. That might be too confusing, but a scheme like that would 
make it possible for us to ensure we don't have name clashes regardless 
of port configuration, while avoiding the need to add namespaces all 
over the place.

 * We could run all source files through a script that looks for 
file-static symbols and manually renames them to include the filename. 
Of course that would  itself slow down the build, but this would have 
the least overall impact on our development. The script would need to 
be smart enough not to touch class-static functions in C++ classes that 
are declared in source files.

Michael