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

> On Aug 28, 2017, at 8:10 PM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
> 
> 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.)

There are several solutions that we could do here. We can forward declare the static functions and have definitions closer to where they are used. I’m also not sure that wrapping statics in namespace is all that bad but I do agree that it’s quite unattractive. We could also have multiple clusters of namespace FILENAMEs as we see fit.

> 
> 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.

I’m not sure this is actually true JSC uses a lot of static functions. Also, I wrote a script that does much of the conversion automatically and I can manually clean up the rest. I’ll put some different versions of files on bugzilla so we can all take a look at what we think the best way to use the namespace is. Although, I think the right answer is to likely rely on taste.

> 
> 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.

I had considered something like this. Ultimately, I decided the FILENAME solution was better because it lets us use descriptive names without having to unique the name. When new cpp files are added to the project, if we don’t use a namespace solution new errors in totally unrelated files may appear due to reordering of the unified source lists. For new developers, errors exclusively in .cpp files they didn’t touch would be particularly frustrating and confusing. e.g. They add Foo.cpp which causes Bar.cpp and Baz.cpp to get bundled together causing a redefinition error in Bar/Baz.cpp. While, new developers might also be annoyed with the FILENAME solution, it’s a pretty simple rule to follow and it doesn’t lead to the same surprises. 

> 
> * 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.
> 

Having the build script change source files seems dangerous and prone to introducing bugs. If we copied the files elsewhere then the source in the debugger wouldn’t match the source in your editor, which seems extra confusing for people not in the know. I’m not saying this isn’t a viable solution but I think it has a lot of perils.

> Michael
>