One of the cooler things that's happened at WWDC this week (other than that minor Monday announcement) is the launch of a new Apple open-source site. The WebKit Open Source Project is the new home of all work on WebKit, WebCore and JavaScriptCore. These are the frameworks behind Safari (and other applications). This is exciting for a number of reasons -- bugs and fixes are now publicly viewable, and if you're much brighter than I am, you can even modify the code and submit bug fixes and new features back to Apple for possible inclusion in the next official Safari release. But since I lack such skills, I found the most interesting bit to be this: you can now build your own version of Safari from code that's newer than the latest public release.
Why might you want to do this? Because the Safari team is constantly rolling fixes and enhancements into the code base, and sometimes, it's nice to have those new features now rather than later. Consider, for instance, the browser stress-test known as the Acid2 Browser Test. This test is designed to see how well browsers support some of the more leading-edge features of HTML and CSS, and how well they deal with errors in such code. The final output is quite simple -- a smiling face. But it's built using some complex code, and not many browsers do very well at it.
Below is a comparision picture showing how well the two versions of Safari do at the test. On the left is the released version of Safari, in the middle is the built-from-source version of Safari, and on the right is the ideal "reference image" for what you should see.
![]() |
![]() |
![]() |
As you can see, the built version of Safari handles that page much better (the left-most image has been trimmed, too. The red-orange fill extends to the width of your browser window). This new version also loads pages faster, and has a number of other bug fixes. Best of all, installing this version of Safari does not replace your current version of Safari, so you actually have the best of both worlds -- as there are some risks associated with using bleeding-edge source code, it's good that the old version is retained. What you're actually building are the new frameworks within Safari, and these frameworks do not overwrite the default ones. You'll use the Terminal to launch your modified Safari while a double-click in the Finder will launch the standard Safari.
Read on for how I built it from source, as well as a couple of gotchas to watch out for. And the usual disclaimer applies: although this hint should not hurt anything on your machine, it's possible that it just might. So please, have a recent backup, and proceed at your own risk (which should be minimal; this is pretty simple stuff). If you're comfortable typing and editing files in the Terminal, have XCode installed, and don't mind a bit of waiting, then you can probably get through this process (Apple has made it quite easy).
The Getting the Code and Building Webkit pages of the Apple site contains detailed instructions on exactly what you'll need to do. If you have lots of experience with compiling applications, just head over there and follow their directions. I'll repeat their instructions here, with added details based on my experience. I'm assuming you have XCode installed (version 2.0, not the newly available 2.1. If you have 2.1, you'll need to modify the installation process), the Terminal open, and that you know how to edit files in the Terminal. I'm also assuming you have not checked things out from CVS (see below) before, nor have your own already-existing builds directory. If any of the above is false, modify these instructions based on your setup.
- The WebKit code is stored in something called a CVS, or Concurrent Versioning System. To download the files, open the Terminal and type these commands (text marked /* like this */ is a comment; don't type any of it):
The last step will start a long string of onscreen updates, and when it's done, you'll have the WebKit files on your local machine. Once you've done this once, you can update your version at any point by running this command from the builds directory: WebKitTools/Scripts/update-webkit$ cd ~ /* change to your home directory, just in case you're not there. */ $ touch .cvspass /* required to make CVS access work -- only needed once */ $ mkdir builds /* the new build directory; do not put spaces in its name */ $ cd builds /* change to build directory */ $ cvs -d :pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root login /* the above command connects to Apple's WebKit CVS. Enter 'anonymous' */ /* for the password when prompted. */ $ cvs -d :pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root co -P WebKitTools /* check out (download) the WebKitTools module */ $ WebKitTools/checkout /* this script does the rest of the hard work */ - Now it's time to build the code. First, launch XCode (in /Developer/Applications), and open its preferences. In the Building section, click the 'Customized location' button in the 'Place Build Products in' section. You need to point it to a directory containing the files you're about to download. Given the number of files involved, it's best to create a new folder somewhere. Make sure that the path to the folder does not contain any spaces. I created a builds folder inside my user's home folder. As such, the path I entered here was /Users/robg/builds. Don't change anything else, click OK, and quit XCode.
- In the Terminal, make sure you're in your builds directory (cd ~/builds), then type WebKitTools/Scripts/build-webkit. Now sit back and wait. And, depending on the speed of your machine, wait some more. And maybe a bit longer. OK, just a touch more. Watch all the pretty text go flowing by. Doesn't it look nice? Almost done now. There! You finally have your Terminal prompt back.
- You didn't install the full XCode package. This tripped me up at first, as I had chosen to not install some pieces of the Dev Tools that I didn't think I'd ever need. I re-ran the XCode installer and selected basically everything other than documentation, and my second attempt at compiling worked fine.
- You have version 2.0 of Bison installed via Fink or some other method. OS X includes Bison 1.28. Bison is a "parser generator" (whatever that may be) that's required for the compilation to work. I'm not sure of the workaround for this one; I think it involves removing the paths to Bison 2.0 from your PATH so that only the stock version 1.28 is seen by the scripts.
- You have a space somewhere in the path to your builds folder. Remove the space and everything will work fine. Make sure you manually update the setting in XCode's preferences, too!
- The path you set in XCode differs from the one you're actually using in the Terminal. Make sure XCode points to the same folder you're using in the Terminal.
However, when I tried the run-safari script, I got this error:
Can't find executable at /Users/robg/builds/Deployment/JavaScriptCore.framework/
Versions/A/JavaScriptCore; have you built successfully?
Since I'd just watched the compile finish, I knew I'd built successfully. Thanks to nkuvu in this thread on the macosxhints' forums for finding the cure. For both he and I, a modification to the run-safari script was required. I haven't seen this mentioned elsewhere, so I'm not sure why. But the fix is quite simple. Navigate into the WebKitTools/Scripts folder, and open run-safari with your favorite editor. Jump to line 48, which will look like this:
$productDir = "$productDir/Deployment";
Change it to this:
$productDir = "$productDir";
Save the file, quit the editor, and try the script again. Bingo! Welcome to the new Safari. From now on, just use run-safari when you want to load Safari with the new frameworks, and double-click Safari's dock icon to run it with the old frameworks. The version I built last night seems quite stable, and I haven't found any obvious bugs yet (though I'm sure there may be some in there). I don't intend to build a new one every night, but I will keep an eye on Surfin' Safari, which is Safari lead engineer's Dave Hyatt's blog, for any notable updates to the source.




