Bug 107333 – [CMake] Build webcore using cmake's object library feature

• Component: Tools / Tests
• Status: UNCONFIRMED

Created attachment 183558 [details]
patch

The proposed patch utilizes cmake's object library feature introduced in 2.8.8. This patch provides the option for users to compile WebCore source files into object files but does not link archive or link them into a library file. Instead the object files may be included in other targets created by add_library or add_executable by listing the object library as a source with special syntax $<TARGET_OBJECTS:objlib>, where "objlib" is the object library name (which in this case is webkit).

By doing this, webcore avoids having to link and thus reducing webkit build time in general.

[Thiago Marcos P. Santos]

(In reply to comment #0)
> Created an attachment (id=183558) [details]
> patch
> 
> The proposed patch utilizes cmake's object library feature introduced in 2.8.8. This patch provides the option for users to compile WebCore source files into object files but does not link archive or link them into a library file. Instead the object files may be included in other targets created by add_library or add_executable by listing the object library as a source with special syntax $<TARGET_OBJECTS:objlib>, where "objlib" is the object library name (which in this case is webkit).
> 
> By doing this, webcore avoids having to link and thus reducing webkit build time in general.

The problem of bumping CMake's version is that most of the EFL developers are using Ubuntu 12.04 on theirs development machine (and on our bots) and it ships CMake 2.8.7. The reason being because it is the latest LTS (Long Term Support) release. That said, I cannot support this change.

[Dominik Röttsches (drott)]

Comment on attachment 183558 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=183558&action=review

> CMakeLists.txt:115
> +SET(USE_WEBCORE_OBJECTS 0)

Maybe you can set this depending on the CMAKE version and keep the syntax compatible with older versions?

[Dominik Röttsches (drott)]

(In reply to comment #0)
> By doing this, webcore avoids having to link and thus reducing webkit build time in general.

Do you have some figures of the impact?

In terms of stats:

Building the blackberry port of webkit, I've seen an average of a 4 minute decrease in build time. Granted I am building on an SSD, linking times in general are shorted.

To elaborate on my previous comment, it generally takes 15 minutes or more to build webkit on average. Now it take 11 minutes.

[Thiago Marcos P. Santos]

(In reply to comment #5)
> To elaborate on my previous comment, it generally takes 15 minutes or more to build webkit on average. Now it take 11 minutes.

Are you comparing it against building WebKit using SHARED_CORE?

[Thiago Marcos P. Santos]

I'm going to clarify my points and concerns here. When measuring performance of a buildsystem, what I'm most concerned is the performance from the developers perspective. It is good if we can save time on the bots, but not if the tradeoff affects the developers routine.

If I understood the proposed change correctly, we are not going to link WebCore anymore as a single object to relink it again when linking the ultimate target: libwebkit.so. Instead, we are going to get a handful of shared objects.

When developing a feature for say, WebKit2 API, I usually build as the follows:

webkit-efl/WebKitBuild/Debug$ make ewebkit2/fast

Which will build WebKit2 API only and link it against libwebcore. It takes 2 seconds on my machine in average. It wont be possible anymore because there will be no libwebcore to link against.

Currently our final target is the sum of: webkit2 + javascriptcore + webcore + wtf. If we don't link webcore, people working on any of these components will always have to link it in order to test their changes.

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #7)
> If I understood the proposed change correctly, we are not going to link WebCore anymore as a single object to relink it again when linking the ultimate target: libwebkit.so. Instead, we are going to get a handful of shared objects.

Just one small correction: this change does not generate a handful of shared objects (.so files), but rather only generate the object files (.o) without linking them together into a .a file at the end.

[Thiago Marcos P. Santos]

(In reply to comment #8)
> (In reply to comment #7)
> > If I understood the proposed change correctly, we are not going to link WebCore anymore as a single object to relink it again when linking the ultimate target: libwebkit.so. Instead, we are going to get a handful of shared objects.
> 
> Just one small correction: this change does not generate a handful of shared objects (.so files), but rather only generate the object files (.o) without linking them together into a .a file at the end.

Thanks, that's what i meant.

(In reply to comment #6)
> (In reply to comment #5)
> > To elaborate on my previous comment, it generally takes 15 minutes or more to build webkit on average. Now it take 11 minutes.
> 
> Are you comparing it against building WebKit using SHARED_CORE?

No, I am comparing it against building WebKit with default options

From looking at webcore's CMakeLists.txt, I see linking is done in TARGET_LINK_LIBRARIES(${WebCore_LIBRARY_NAME} ${WebCore_LIBRARIES})

What if I moved ${WebCore_LIBRARIES} to link with webkit? would that fix this issue?