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

[Mike Emmel]

I refactored all the Unicode handling to run behind a abstract interface.
So no direct ICU calls.

Its a lot of little patches all over the place and a thankless job.
Its a lot of work so email me if your interested.

I was also looking at repacling icu with glib/pango.

Its not clear you get everything you need from glib so I believe you
have to bring in pango
which does more than you want.  Pango itself needs to be split into text metrics
and glyph drawing.




On Nov 12, 2007 3:28 AM, Alp Toker <alp at atoker.com> wrote:
> 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.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>