Home > GHUnit, iPhone, Testing > GHUnit: New Buildsystem

GHUnit: New Buildsystem

Managing a project’s source is always challenging, especially when external dependencies are involved and even more when they aren’t binary but source dependencies. That’s how it is with GHUnit.

In my attempt to integrate OCMock, I therefore decided to create a new build system for GHUnit. GHUnit needs to be built for two different platforms: Mac OS X and iPhone OS (Simulator and Device). The first is built as a framework, while the second is built as a single static library combined out of a static simulator and a static device library. Originally, GHUnit made use of the following structure:


  • Classes  // common classes
  • Classes-IPhone // iPhone classes
  • Classes-MacOSX // Mac OS classess

There was an initial structure, not bad. The problem was with the XCode Projects. They were contained in subfolders called Project and ProjectIPhone. To make things worse, the iPhone project contained two different targets for building device and simulator versions with otherwise identical settings. A third target was used to combine them and create a zip archive with the static libraries and the headers that need to be redistributed. Thus, adding a new file to GHUnit would require adding it two three targets in two different solutions. Not nice.

I therefore decided to reorganize the source code and unify the different projects and targets into a single project. Releasing should be a one command action and is therefore done via a simple makefile. The project structure looks now the following:


  • src
    • Classes  // common classes
    • Classes-IPhone // iPhone classes
    • Classes-MacOSX // Mac OS classes
  • test // tests
  • build // build output
  • buildIPhone.sh // buildscript for iPhone, builds simulator and device versions and combines them in a single binarie
  • buildMac.sh // buildscript for mac
  • Makefile // invokes redist targets (see below) / runs unit tests

The single project now has a two main targets (for iPhone and mac) and a redist target for each of  these versions. The redist target is necessary to configure the build environment. Afterwards it invokes the appropriate build script.

External dependencies can never be binary becuase iPhone OS only allows static linking. It is far easier to include the sources into GHUnit and compile them into its binary. For GTM, GHKit and BWToolkit dependencies are only on a very small subset of the code. Considering the slow pace of these projects, including the whole projects would be too much overhead. Because GHUnit doesn’t attempt modification of OCMock but a full inclusion the whole OCMock svn trunk is included in the lib/OCMock folder. Some small adjustments on the OCMock Source were nescessary to make it build on the iPhone, I hope these will get included in the official trunk of OCMock.

Categories: GHUnit, iPhone, Testing
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: