GSoC preparations – part 1

The official GSoC coding phase hast not started yet (will start on May 21th) but of course, I already did some research and preparations (as is also suggested by Google) in order to be ready when it does. In this post, I put together some thoughts and findings that occured to me while prep’ing. This is part 1, there will be a part 2 soon ^^

Enter bockbuild

First step when working on a project is setup a build environment. I did this already before my actual GSoC application, so I can get a better understanding  and estimate the effort necessary to integrate the BCE into banshee’s current build system. When building software that originates on Linux for Mac, you inherently face the problem that there is no package repository tool available as you would expect from a linux system (apt, zypper, etc.). You can’t just do a “zypper si –build-deps-only” to install the required dependencies  as I would do on my openSUSE box. And if you go for fetching and compiling every little dependency yourself, you will soon realize that it comes to more than 60 different software packages (for banshee), each in their own tarball, git repo or whatever, and each possibly dependent on another package(s). Eventually, you will be lost in compilation.

This is where bockbuild comes into play. Created by Aaron Bockover, bockbuild takes care of fetching and compiling the sources from scratch in the correct order and installs them all together into a single $prefix. This includes building build tools (like autotools and cmake), gtk and its dependencies (cairo, freetype, glib etc.), gstreamer, a full mono environment and finally the bunch of banshee dependencies and most of the C# wrappers to the aforementioned libraries.

On my development machine (a 2008 Macbook white with a Core2Duo and SSD) the whole process of fetching and building the environment takes about 2,5 hrs. Because one would not rebuild the entire world after each tiny package upgrade  (bumping a tarball to a newer version or moving to a newer git commit), one can simply recompile the modified packages. This is where it gets messy. While the recompilation of a single package may succeed on the pre-setup world, a completely new build of the world from scratch could fail. This is one of the reasons I spent almost two days before my application for GSoC to patch bockbuild for my system to successfully compile the world – just in order so I could compile a recent banshee version on my machine. The whole process is very painful and I wouldn’t recommend it to anybody – maybe a reason why to this date there are not that much banshee developers based on OS X. I decided to change that, or at least lower the bar for other developers to get their hands on banshee on the Mac.

Better testing of bockbuild

As the build results of bockbuild when building the world are dependent on dozens of factors, I needed a clean-room environment where I can test the builds and later on the .app bundle. Now that I am sponsored by Google and knowing that I  will (hopefully) soon receive my initial funding, I did not hesitate to spend some of Google’s money to back my development process: I acquired a copy of Parallels 7 (which comes as a full-version educational edition for 39,99 €) which allows me to run virtualized versions of Lion and – with a little hackery  – my old Snow Leopard DVD non-server version.

I am really no big fan of Parallels, they don’t seem to treat their customers well (pop-up ads for their own products as well as crapware bundles like Kaspersky subscriptions etc), but I’ll maybe blog on that later. For now,  Parallels 7 will give me a playground to accomplish my next goal:

Stable bockbuild releases

In order to allow other developers (and users!) to compile banshee from source and roll their own AppBundle, I’ll try to maintain two branches in my GitHub repo:

• a -stable branch, which is tested to build completely from scratch on different OS X installations with different settings. It is alligned with the banshee releases – for now I created a banshee-2.4-stable branch which could be used to build banshee 2.4 and roll your own AppBundles
• a –testing The master branch which someday will eventually turn into banshee-2.6-stable branch. Patches against this branch might cause the build world to fail, as it is not tested everytime a change is made. Use at your own risk!

Now the branches are setup, but documentation on building the world and banshee on OS X are a little outdated – I will give more detailed instructions in a future blogpost, where I will also tell more about how to easily setup MonoDevelop to compile and run banshee for your development purposes.