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 [EMAIL PROTECTED] wrote:
Mike Hommey wrote:
On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED]
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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
