This a post about using Xcode’s distributed build feature to shorten your development cycles. Many indie developers are constantly seeking a way to shave a few seconds off the edit-build-debug workflow. If you have more than one Mac at your disposal, or even if you work in a small team, you can effectively pool compile resources to speed build times.
When I worked on very large projects at Avid we were saddled with hours-long build times. Xcode 2 introduced the distributed build feature, which really was a godsend to us. Products were typically built from millions of lines of code in tens of thousands of files spread out over hundreds of projects (or Solutions on Visual Studio). On Windows we started using Incredibuild with great success. Yes, the incremental builds were still sort of slow, but full builds went from 8 hours to under an hour. Incredibuild was good, but came with a hefty per-seat license fee.
On the Mac side we started looking into Xcode’s distributed build, based on the distcc and gcc technologies. This proved to be a great boon to us, too, even though there were some issues to work out. For starters, Xcode’s implementation uses Bonjour (Apple’s zero-config service discovery protocol) which means all resources must be on the same subnet. While this is not a problem for you the indie developer, a corporate environment has numerous subnets, so “discovery” of your cubicle-neighbor’s system is not always easy. Also, we made heavy use of pre-compiled headers in previous attempts to shorten builds, and this causes issues with distributed builds. Again, probably not a problem for most of us, but in a very large team where you might be modifying a header locally, that will certainly screw up somebody else’s build.
Fast-forward five years and now I am doing solo iPhone development, where the largest projects are a few dozen files that take 5 minutes to build. Not a big deal. Until you add OpenFeint, that is, or maybe cocos2d, or some other third-party repository, to your project. I have one project that takes 14 minutes to build on my Unibody MBP, thanks to OpenFeint. Certainly there are other techniques to help alleviate this, such as building OpenFeint as a separate static library, etc. But for the purposes of this discussion, let’s continue with the distributed builds.
I had two Macs until very recently, and one of them is hardly used for development. I updated the Xcode on it and turned on distributed builds, and that 14 minute build went down to 9 minutes. The beauty of distributed builds with Xcode is you set it and forget it. There’s no need to keep Xcode running on the other system(s), or remember passwords or futz with permissions. All you need to do is make a reasonable effort to have all the systems use the same version of the Xcode tools. Xcode will show (in the preferences window) which clients have compatible versions; this make it easy to identify which machine is not “playing nicely.”
If you need to you can create different “sets” of machines which have different capabilities. The default set is simply called Bonjour, and it will automatically include any and all machines available at build time. If you happen to be on different subnets or otherwise can’t find the other systems with Bonjour, it’s also easy to add devices manually to the list. Just press the + button below the right-side list of machines for that set.
Best of all, building with the distributed builds is simple. You don’t have to do anything differently. Just build & run or build & debug as usual. Xcode’s activity window and status lines will say “distributing build … ” now instead of just “building … “. For those doing automated builds, I think the xcodebuild tool will use distcc automatically if it’s enabled in Xcode’s preferences.
So if you have a second or third Mac in your shop, put it to work and save yourself some time!