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 +0000, 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