Compiling Awesomium

From Sirikata Wiki
Jump to: navigation, search

Note: If you have Windows, do not bother trying to compile Chromium/Awesomium unless you have the Standard or Professional edition of Visual Studio 2005/2008, which costs money (most universities have a MSDN or eAcademy subscription which will provide VS2008 at no cost). If you use Express, it will *almost* compile and you will waste hours trying to kludge around with missing headers and nested project files. See here for more information:

Note2: The installation process was very painless with VS 2008. 2005 requires the latest Platform SDK, and the Windows SDK Configuration Tool kept crashing. The way I fixed it was to rename VC/PlatformSDK, and I created a junction point (NTFS symbolic link) to the actual platform SDK. Seeing as 2005 is the officially supported build environment, I may have made some mistakes.

Compiling Chromium

Compiling chromium takes a huge amount of disk space (I'm talking 10's of Gigabytes), so be prepared with plenty of reserve. It's far worse under Windows of course, but Linux and Mac are also bad. You can shave off quite a bit by compiling in Release, but then you can't debug if something goes wrong.

On all platforms: Set up a directory tree as follows:

git clone git://github.com/pathorn/awesomium.git
mkdir chromium

Follow the "bootstrap using the tarball" instructions at [1]. Install the depot_tools, and download the chromium source tarball. When you extract it, it will create a big directory tree, like home/chrome-src/.../chromium. Find the "chromium" directory, and move it inside the chromium directory that you made. The heirarchy should now look like:

awesomium
 \-Awesomium
   \-src
   \-include
 \-debug
 \-app
 ...
chromium
 \-chromium
   \-src
     \-chrome
     \-base
     \-...

Now, go to chromium/chromium (outside src) and run "gclient sync --force --revision src@18798". Note the "--revision" argument. Because Awesomium depends on the chromium internals, it can get out of date rapidly, especially with the current trend of moving all the classes into WebKit. To get an idea, I had the chromium repo change between checking out one copy for vc8 and another for vc9 (I made the mistake of not specifying a revision).

If you want to update to a newer Chromium, you have been warned. If you feel up to the challenge, you can fix whatever comes up. Google pretty heavily documents their changes, and the test_shell diffs usually tell you what sorts of changes need to be made.

One more thing: Because Awesomium does not make use of the multiple process IPC mechanism, and runs everything in a single process, some code will crash if Awesomium is not running on the "main thread". To work around this, go to chromium/src/third_party/WebKit/JavaScriptCore/wtf/ThreadingPthreads.cpp (Linux/Mac) or ThreadingWin.cpp (Windows). Then search for the "isMainThread" function. Replace the contents with a simple "return true;". This appears to have no adverse consequences as of yet. However it is now the application's responsibility to ensure that Chromium code is only run from a single thread. This is the one and only change you should have to make to Chromium code itself.

Here is where things start to differ for each platform.

Linux (x86 or amd64)

Note: Currently we can only link with 32-bit chromium. While chromium already seems to have an IPC mechanism (potentially for allowing the child to remain in a separate 32-bit process), we currently keep the whole thing in a single process. Therefore, anything you link with chromium must also be 32-bit.

Luckily, it is easy to compile a 32-bit binary from a 64-bit system. The google scripts do all of this for you.

Build Chromium using these instructions. http://code.google.com/p/chromium/wiki/LinuxBuildInstructions

Mac OS X

See here: http://code.google.com/p/chromium/wiki/MacBuildInstructions

XCode should come with Leopard, and the compile process should work out of the box. This is one nice thing about having a standard platform.

Windows XP

http://dev.chromium.org/developers/how-tos/build-instructions-windows

Aieee. This platform felt like it should be the easiest since windows is chrome's main platform right now. VC++ 2008 was pretty painless. You will need to upgrade the "Solution" file, just hit next a couple times. I think you can build the whole solution. Once you start getting into test_shell code you can probably choose to stop the build.

VC++ 2005 needed all sorts of kludges to compile. The most important thing is to make it use the Windows Server 2008 SDK instead of the default. If your windows machine is not as screwy as mine, the SDK Configuration Tool should hopefully Just Work. If not, you may need to be tricky about renaming away the default SDK so that it won't find the wrong set of headers. I also ran into about 5 different compile errors involving various Platform SDK headers. Most weren't too hard to fix.

Awesomium

Now that you have chromium compiled, go into the awesomium directory.

Linux

Go to Awesomium/src and type "make". If you run into linker errors, note that the ordering of ".a" files matters in the Makefile. And, the more times you duplicate a .a file, the longer it takes to link.

Mac OS X

Open up the Awesomium.xcodeproj. It should just compile out of the box. The Mac does incremental linking, so it seems to go pretty quick.

Windows XP

Open up Awesomium.sln. On VC++ 2008, you'll need to "upgrade" the project again. You may run into a couple of missing libraries, so be prepared to add them into the Properties -> Linker.

The "app" program is windows-only. Don't worry if the "app" program doesn't compile. If you want to play around with it, you can add Sirikata's dependencies to the project include path and library path -- specifically boost_1_37_0, ogre-1.6.1, and ois-1.0.

Integrating your compiled library into Sirikata

Make a folder called "awesomium" in the dependencies directory. Copy the Awesomium/include folder here. Also, copy the "Debug" folder *outside* of the capital A awesomium, but inside the lowercase a awesomium. This one should have a .dll, a .lib, and unit_test.exe. Put that inside dependencies/awesomium, and rename to "lib". If you are mixing and matching debug and release, feel free to add or remove the "_d" extension on the .lib, dependending on which you want (the .dll stays the same).

git pull the "awesomium" branch and run cmake. It should find the AWESOMIUM_ROOT.

Note that on Linux you're going to have to build Sirikata in 32-bit. This means you'll need a separate dependencies folder, and you'll have to somehow trick the dependencies into giving you a 32-bit binary. This is a problem, and it's one of the reasons that the awesomium branch is not merged into master yet.