On Mon, Aug 28, 2017 at 7:37 PM, Keith Miller <keith_mil...@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.


webkit-dev mailing list

Reply via email to