How to work on WebKit

As you should know, Ryan and I worked actively on the WebKit port during this summer.
I won't say this port is perfect, because many parts need to be improved and stabilized. Anyhow, I think it's a good idea to provide a way for people to build it and not moving in the dark. Building WebKit on Haiku isn't so hard but can be really long.


WebKit has some dependencies. So here is how to fill these requirements:

  • GPerf
    Aka GNU perfect hash function generator (for more details, see official site), this tool is used to generate some source files. You don't need more than the executable file (gperf), which can be put into /boot/common/bin.
  • ICU
    These libraries are already in Haiku (there are required by the Locale Kit), but it lacks the unicode headers. You may find them in Haiku source code under headers/libs/icu. The entire unicode directory should be copied into /boot/common/include. (To be discussed: Including them in the image? (We don't want this, people should use the Locale Kit instead); Provide an optional package and warn people that they shouldn't use it?)
  • Curl
    For Curl, you can get it as optional package.
  • Perl
    Perl is basically available on Haiku.
  • GCC4
    GCC4 is basically available on Haiku. Note that you cannot build WebKit using GCC2.
  • Maybe Python and Ruby
    Python and Ruby aren't really necessary. Actually, Python is used in some non-vital scripts such as webkit-style-check. And Ruby is needed once, when running the tests (which aren't faithful on Haiku for the moment).
  • And of course, the source code.
    Most of the code is already on the official WebKit repository. But some parts of the code aren't available for the moment. So, if you try to get the code from the official repository, you may lack the build system (including Jamfiles and Jamrules), the API (which, to my mind, isn't stable enough to be included now), and some parts of the code I worked on but didn't find the time to commit them on the repository. (The commit process is indeed a bit more complex than on Haiku, but it's totally understandable according to the number of different ports.)
    And then, the easiest way we found for people to test our port, or even to help us, was to create an external repository which contains a "not-so-outdated" version of WebKit (I will try to merge from the official tree as often as possible), plus the required files.
    (Though this is a temporary solution before all the great stuff is included in the official repository. Then it would remain a "staged area" for development purpose.)
    So, to get the code, you have no choice but to use git (Yes, I'm pretty vicious.):
    git clone git://

Building WebKit

Building WebKit is a double pass compilation.

First you need to generate some files. This is done with this command

$ sh WebKitTools/haiku/

Then the second thing to do is to build the code. There are multiple targets that are automatically copy into your ~/config/{bin,lib} directory.
The target names are:

  • (the JavaScriptCore library)
  • jsc (the JavaScriptCore executable shell)
  • (the WebCore library, including
  • (the WebKit library including, the API and some specific files)
  • HaikuLauncher (the test shell, including and a simple browing window)
  • DumpRenderTree (the tree parsing tool, required to make crash-tests on WebKit (with files from /LayoutTest))
So to build one of them you may do this command
$ jam -q *target*
You can speed up the build using -j2 instead of -q, but you won't be able to know where the build crashed (if it crashes…).


The WebKit port evolves really fast, so you may run into troubles when building it with a recent version of WebKit.
We are making our best for this not to happen, but you're warned. :) Also, if you have some problems (even when following this tutorial line-by-line), I will be pleased to help you.