[webkit-dev] Moving away from qmake (aka. modularising
mike.emmel at gmail.com
Mon Nov 12 10:05:46 PST 2007
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
> >> as a standalone scripting engine independently of WebKit.
> > 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.
> obvious issue is the set of platform/language bindings. Luckily the fix
> for this is pretty obvious, and I've filed a bug:
> 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:
> [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
> 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
> between ports. Lots of effort for minimal gain.
> in my use case was that it made it far more practical to hack on the new
> 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
> 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
More information about the webkit-dev