[webkit-dev] Moving away from qmake

[Alp Toker]

The existing qmake-based build system is shared by the GTK+ and Qt ports.

Until recently, this arrangement has not been too problematic for the
GTK+ porters, with the idea being that qmake makes life easier for
developers at the expense of a little inconvenience for users (in the
sense of application developers rather than end users).

However, it has recently become clear that qmake is actually making life
more difficult for developers. It turns out that the existing qmake
build system fails to do basic dependency tracking, leaving both
developers and users with crashy builds, with the only way to get a
stable build being to do a full clean and rebuild after every update.

In the last week I've had to explain why people's builds are crashing to
maybe half a dozen people on WebKit and GNOME-related channels.

Mark and I have attempted to fix the dependency tracking a number of
times, but we've both found qmake to be poorly documented, and our
attempts to fix it ended up breaking the build even more in certain
configurations. My informal attempts to get assistance from the
Trolltech guys doing the Qt port have gone unanswered. I have no doubt
that we would be able to fix these issues in a matter of minutes using a
better understood or documented build system.

Moreover, it has turned out that the qmake build dependency is more than
just a little inconvenience for users. It makes the GTK+ port
inaccessible to a lot of developers. Using anything but the latest Linux
distributions, including cross-compilation frameworks like Scratchbox,
you have to build the whole of Qt just to get qmake, which takes over an
hour and almost a gigabyte of disk space for me. That's at least 5 times
as long as it takes to build the whole of JavaScriptCore, WebCore and
WebKit. Even in distributions that ship a recent binary of qmake, it is
often bundled into the same binary package as the rest of Qt, making it
a seriously large dependency.

Now that the GTK+ port is getting attention from beyond a core team of
developers, I think such a heavy build dependency is no longer acceptable.


If either the Wx or Qt porters are willing to share a new build system
with the GTK+ port, they should speak up now. We're willing to consider
any build system that does not incur a huge dependency (ruling out
qmake) and that is actively maintained and does not have verbose XML
makefiles (ruling out Bakefile and Ant-like build systems respectively).
cmake and autotools are fair game here, for example.

If we cannot reach a conclusion, the GTK+ port will most likely go ahead
and switch to autotools. Work has already started to provide an
autotools-based build system at
http://git.ndesk.org/?p=javascriptcore-modular

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.


I hope I've accurately summarised the thoughts of all those involved here.

(It's quite unfortunate that we might end up contributing to the current
proliferation of build systems, but I think it's fair to say that the
qmake dependency is right now the biggest single issue holding back
development and acceptance of the GTK+ port. If other ports are willing
to compromise in the same way as we are on a shared solution, this
proliferation can still be avoided.)