[webkit-dev] Moving away from qmake (aka. modularising JavaScriptCore)

[Alp Toker]

Mike Hommey wrote:
> On Mon, Nov 12, 2007 at 03:34:48AM +0000, Alp Toker <alp at atoker.com> wrote:
>   
>> An unforeseen benefit of the new build system is that it is modular,
>> rather than monolithic, and has no dependency on GLib/GTK+ or any other
>> framework. This means that it will now be possible to use JavaScriptCore
>> as a standalone scripting engine independently of WebKit.
>>     
>
> Except that for the moment, JavaScriptCore is a little bit different if
> built for the Qt port or the Gtk+ port, so it couldn't be shared between
> both, which is pretty sad, actually.
>   

I can go into the issues here a bit further, though it doesn't directly 
relate to the choice of build system.

When it comes to platform-specific code in JavaScriptCore, the most 
obvious issue is the set of platform/language bindings. Luckily the fix 
for this is pretty obvious, and I've filed a bug:

http://bugs.webkit.org/show_bug.cgi?id=15931
Eliminate Instance::createBindingForLanguageInstance()

The other instance of platform specific code that I can see is Qt's use 
of Unicode functionality, while other ports tend to use ICU. I've 
actually been planning to port the Unicode abstraction to use GLib, 
since ICU is a very heavy dependency for non-desktop systems. (There is 
potential to shave up to 10M off the distribution size of the GTK+ port 
for mobile devices here.) This is however a thankless job that nobody 
else seems to be interested in doing and I've put it off till now:

http://bugs.webkit.org/show_bug.cgi?id=15914
[GTK] Implement Unicode functionality using GLib

So this would actually be a step away from re-usability as a shared 
library but a step towards a lower mobile memory footprint.

There are a few other bits of Qt-specific code such as that in DateMath, 
but these do not seem significant, and if the other two issues were 
fixed I imagine the Qt developers would be happy to compromise on those.

As long as ports work to avoid ICU for Unicode functionality, I don't 
think we're going to get around to genuinely sharing JavaScriptCore, and 
to be honest, I don't see this being a real problem. How many people 
will run Konqueror and Epiphany at the same time (for reasons other than 
testing)? Will those people who do regularly use both Konqueror and 
Epiphany miss the 1-2M that could have been shared given that the 
complete applications are taking at least 10M each?

So while I think there is the possibility of having a standalone 
JavaScriptCore edition embedding into applications, I do not think there 
is any immediate hope of having a single JavaScriptCore library shared 
between ports. Lots of effort for minimal gain.

The real benefit in having a standalone build profile for JavaScriptCore 
in my use case was that it made it far more practical to hack on the new 
CLR/JavaScript binding. This would have been really unpleasant if I had 
to build and link the whole of WebKit each time I made a change. I think 
that lowering the barrier for new JS bindings alone is a good cause for 
having a modular JavaScriptCore build target, but maybe I'm the only one 
developing new JS bindings right now?

> As for switching away from qmake, I'm all for it, though I have no problem
> having to use qmake for the Gtk+ port, since I'm already building both Qt
> and Gtk+ ports in one pass for the Debian packages. I'll only add this: it
> would be nice to avoid linking to indirectly used libraries where possible,
> though it may be challenging. (I'm using -Wl,--as-needed for that matter)
>
> Mike
>   

You and I have learnt how to deal with qmake, but I've recently 
discovered that casual contributors and potential adopters in GNOME are 
taking one look at the qmake build system and turning around. It also 
seems to be antagonising people who use source-based distributions like 
Gentoo and who would otherwise never have a reason to take an hour out 
of their lives building the whole of Qt.