[webkit-dev] Moving away from qmake

[Kevin Ollivier]

Hi Alp,

On Nov 11, 2007, at 7:34 PM, Alp Toker wrote:

> 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.)

Unfortunately, I don't see room to compromise on my end because  
neither autotools or cmake will meet my needs without a fair amount  
more effort on my part (effort I'd rather spend putting into improving  
wxWebKit itself), and I pretty much get all of the other benefits you  
mentioned are obtained by switching away from qmake, so there's not  
really any plus for me. Honestly, I find the Bakefile build system to  
not be very verbose at all thanks to its use of templates, which allow  
me to group together settings needed by various components and reuse  
them easily. The largest files are the *Sources.xml files, but those  
are very light on XML tags and are mostly text files, and are easy to  
update and maintain, IMHO. Over the past couple weeks, I in fact did a  
lot of refactoring on the build system and it was quite quick to do  
and I'm really pleased with the results. I haven't yet found a (cross- 
platform) tool that lets me be as productive as Bakefile does, which  
is the bottom line for me as my time is limited.

The one downside to Bakefile is that it's newer than other systems and  
over time I've bumped into a few rough edges, but most of those have  
gotten fixed. Even with having to make a few temporary workarounds,  
though, I find it saves me a lot of time in other areas that more than  
makes up for it.

Anyway, I won't press the matter; I admit I don't have a Unix  
background and both autotools and cmake build systems look and feel  
like large shell scripts to me, which I personally find hard to work  
with and maintain. People with a Unix background are very used to  
them, though, and seem to prefer them, so I guess it's just a matter  
of different perspectives.

Regards,

Kevin

>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev