[webkit-dev] Moving away from qmake

[Mike Emmel]

Here is my autoconf build files

They are for my current  projects but I think they could readily be
cleaned up to b used with the standard build.
I found that having a single Makefile did not incur any performance problems.


On Nov 11, 2007 7:34 PM, Alp Toker <alp at atoker.com> 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.)
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.tar
Type: application/x-tar
Size: 122880 bytes
Desc: not available
Url : http://lists.webkit.org/pipermail/webkit-dev/attachments/20071111/7b6ca0d0/build-0001.tar