Bug 178968 – [GTK] Build more files under WebCore as unified sources

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

Build more files under WebCore as unified sources (after landing the patch in bug #178964).

[Michael Catanzaro]

It will take some work (and understanding of Ruby) to be able to build WebCorePlatformGTK and WebCorePlatformGTK2 using unified sources, since they are two different build targets that are built with the same sources, and there is a useful check to ensure the same file is not accidentally listed twice that I don't want to remove. Plus I don't really understand that code.

But there are still many files here that can easily be built unified.

[Michael Catanzaro]

Created attachment 325422 [details]
Patch

[Keith Miller]

Comment on attachment 325422 [details]
Patch

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

> Source/WebCore/SourcesWPE.txt:40
> +# This can't go into SourcesGLib.txt because it has to go into WebCorePlatformGTK.

# => //

[Keith Miller]

Comment on attachment 325422 [details]
Patch

r=me if you fix the WPE issue.

[Michael Catanzaro]

(In reply to Keith Miller from comment #4)
> Comment on attachment 325422 [details]
> Patch
> 
> r=me if you fix the WPE issue.

That's not really possible to fix, which is why I removed the FIXME. The problem is that for GTK it needs to be complied into a different build target than all the other files in SourcesGLib. It will just have to be special, I guess.

[Michael Catanzaro]

Oh wait, I misunderstood... I see now WPE is broken because I used # instead of //. Comment #3. Yeah.

[Michael Catanzaro]

Committed r224233: <https://trac.webkit.org/changeset/224233>

[Konstantin Tokarev]

Is it really worthwhile? I don't have any statistics, but from my personal experience it's rather likely that GTK developers should modify platform-specific files more often than port-independent core during their work, and having files built as a part of unified system adds penalty to incremental rebuild time. OTOH, platform-specific files take a small fraction of total build time so speed up in complete rebuild is not so significant.

[Michael Catanzaro]

(In reply to Konstantin Tokarev from comment #8)
> Is it really worthwhile? I don't have any statistics, but from my personal
> experience it's rather likely that GTK developers should modify
> platform-specific files more often than port-independent core during their
> work, and having files built as a part of unified system adds penalty to
> incremental rebuild time. OTOH, platform-specific files take a small
> fraction of total build time so speed up in complete rebuild is not so
> significant.

The platform-specific files actually do have a significant impact on build time. The WPE port builds roughly 25% faster than the GTK port, which is insane. I'm hoping to cut down on this by unifying as much as possible, notably the GTK DOM API, which seems to be one of the major differences between GTK and WPE.

Current limitations:

 * The sources under WebCore/platform are difficult to unify, because the build files rely on USE_[LIBRARY] style flags instead of feature flags defined in WebKitFeatures.cmake. I'm not certain, but I don't believe we can use those in conditionals inside the Sources.txt.
 * We can only unify files that are built into a WebKit framework declared with the WEBKIT_FRAMEWORK macros. This means it's hard to unify the PluginProcessGTK2 build, which is the other main difference between GTK and WPE.

[Konstantin Tokarev]

(In reply to Michael Catanzaro from comment #9)

Thanks for explanation.

> The platform-specific files actually do have a significant impact on build
> time. The WPE port builds roughly 25% faster than the GTK port, which is
> insane. I'm hoping to cut down on this by unifying as much as possible,
> notably the GTK DOM API, which seems to be one of the major differences
> between GTK and WPE.

If only DOM API is unified, could it make a qualitative change?

> 
> Current limitations:
> 
>  * The sources under WebCore/platform are difficult to unify, because the
> build files rely on USE_[LIBRARY] style flags instead of feature flags
> defined in WebKitFeatures.cmake. I'm not certain, but I don't believe we can
> use those in conditionals inside the Sources.txt.
>  * We can only unify files that are built into a WebKit framework declared
> with the WEBKIT_FRAMEWORK macros. This means it's hard to unify the
> PluginProcessGTK2 build, which is the other main difference between GTK and
> WPE.

It may be useful to factorize WEBKIT_FRAMEWORK to be useful for non-libraries, and/or use modern property-based approach instead of relying on variable names. (Actually, I think having unified variable names in all targets is a good thing)

[Michael Catanzaro]

(In reply to Konstantin Tokarev from comment #10)
> If only DOM API is unified, could it make a qualitative change?

I haven't tried it yet. I'll try after bug #182450 lands.