[webkit-dev] Common build system (was Re: WebKit Wishes)

Balazs Kelemen kbalazs at webkit.org
Fri Feb 1 16:58:38 PST 2013


I think one important aspect of build systems was not considered yet int 
this conversation: speed. The time an incremental build takes has a 
great effect on developer productivity. I don't think any of the 
meta-build systems we use does a great job here - although I only have 
experiences with qmake, cmake and autotools (and I don't have an SSD 
that could help somewhat).

The technic I found useful here is to avoid calling build-webkit always 
and instead just rebuild the subproject you have edited, so I think it 
is important to have a build system that supports it. Let me share my 
experiences here.

With qmake nowadays this work perfectly. The developer build is 
producing a shared library for every subdir (WTF, JavaScriptCore, 
WebCore, WebKit2), which means you only need to call make in the 
specific subdirectory (i.e. if I only touched WebKit2 files I do "make 
-C WebKitBuild/Release/Source/WebKit2" which is pretty quick). Still 
WebCore is so big that make is quite slowly find out the files you 
actually edited and need to be rebuilt. What could help here is to 
devide WebCore into smaller parts, like the ongoing work of extracting 
Platform. Maybe the next logical candidate could be svg (I don't have 
real knowledge about how feasible it is).

Note that I don't come up with qmake because I would like to recommend 
it as the one and only build system (in fact it has a ridiculously 
inconvenient syntax, and a lot of bugs), just as an example.

With Cmake fast incremental rebuilds are also possible, maybe in a bit 
more complicated way. When working with the EFL port I found a quick 
rule for WebKit2 in the generated makefile. Although the makefiles are 
usually call back to Cmake, and make is not faster than build-webkit, if 
you use the special fast target, which is something like eflWebKit/fast 
(i.e. make -C WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it 
will not check dependencies but just rebuild the files that have 
changed. I did not find a similar thing for WebCore, I guess because it 
is not built as a shared library.

What I dislike in Cmake is that I am disappointed by how slow a normal 
incremental build with it (i.e. build-webkit). qmake is not faster at 
all, but it generate plain makefiles that typically no call back to 
qmake if not specified explicitly to do so, and directly calling make is 
faster, yet it can handle most of the non-trivial changes, for example 
editing a generator file. I don't know gyp, so I wonder about how would 
it do in this comparison (but I guess it generates simple makefiles as 
well, so it's similar than qmake in this manner.)

I hope I added something to this conversation that is worth to consider 
with my late nightly brain dump.

-kbalazs



More information about the webkit-dev mailing list