In the GTK+ port of WebKit, we use QMake, QT’s make alternative, to build the project. This has become a bit unwieldy to a few contributors and developers as they have to install QT libraries, even the whole QT stack, just to build the GTK+ port. Sounds ironic, yeah. But there are also times when developers had enough with qmake DEPENDPATH issues that changes to the dependencies can sometimes yield unpredictable builds – compile-time and runtime errors.
So, to fix this problem I started to autotool the GTK+ port of WebKit. I am no autotool maestro but I feel it’s something that needs to be done and Autotools is something that I want to learn anyway. Doing the project I’ve realized that autotools is actually a good solution for automatic dependency and host feature resolution. And one thing i’ve also learned when reading Peter Miller’s Non-Recursive Make paper is that (1) Make is GIGO. So if you put crappy rules there then you get what you deserve; and (2) The beauty of Make is that it doesn’t require the user to install additional packages and dependencies – most unices will have Make. And this is very important as WebKit, and the Gtk+ port, is used and embedded environment as well as in the desktop space.
So as of today you should be able to build WebKit/GTK+ using autotools. This should also make it easier for people used to autotools as well as newcomers coming from Gtk+/GNOME expecting an autotool build system for WebKit Gtk+.
Update: Alp posted a brief summary as well plans with regards to the Gtk+ port and autotools build system. It’s also nice to know that other (younger) ports are interested in adopting the build system for their own use.
Don’t want to troll, just to let you know my personal experience on the subject.
qmake is self contained (just need folders with qmake specs). Shipping qmake binaries would have made sense, no ?
My autotools experience was really rought. Cryptic error messages, and you never know which command you should type first (aclocal, autoconf, automake …). And talking about deps, qmake is native, while autotools needs m4, libtool, automake, autoconf, and it might need perl (automake is written in perl ?), and also gettext.
At one point for our project we droped automake, libtool, and then wrote our own Makefiles, computing deps ourselves, ala automake. That was a lot of pain for very little gain.
KDE folks moved away from autotool (that they called autohell), to CMake. I like qmake a lot personaly.
Benjamin
Then why don’t you try cmake instead of qmake?
@Benjamin: the idea with autotools is that the maintainer generates the configure script (using autotools) before releasing, so the end users will only need to have Make installed.
This doesn’t seem to be the case here, though; the autogen.sh file should not call the configure script itself, and the users should not be required to call autogen.sh to build and install WebKit.
@Daniel: autogen.sh is handy for developers and you’re right that users should not call autogen.sh directly, but should call the configure script. That will happen eventually.
Patches welcome!