Friday, October 10, 2014

DerivedData and xcodebuild

If you use Xcode you know about DerivedData. If you don't know DerivedData, you don't know Xcode.

If you are setting up xcodebuilds from the command line, say for continuous build and integration (CI), then you want to make sure you are using that command line the best way possible. Some things I keep running into as I see people's build systems are:
  • Running out of space due to a backup of old DerivedData.
  • Build performance hanging, due to a backup of old DerivedData.
  • Unexplainable build failure, solved by deleting, you guessed it, DerivedData.

If you use the command line for builds then save yourself a lot of trouble in the future. Start using the xcodebuild option -derivedDataPath.

Here are the docs on it:
-derivedDataPath PATH                     specifies the directory where build products and other derived data will go

That one option huge significance. Here are some reasons why I use it and convert build systems over to this option:
  • I can store the DerivedData in the temporary source workspace of automated builds (like CI builds, automated test runs, etc.) When the workspace is cleaned up the DerivedData goes away and net disk space should be 0 at the end of the build.
  • With no shared DerivedData between builds the build performance does not drop due to large DerivedData folders.
  • Without a shared DerivedData folder I see much lower instances of unexplainable build errors. This means less cleanup, less build host reboots, etc.

Personally, I am very interested in how remote builds with Mac OS X Server and Xcode have improve the build process for automated builds. Until I get the chance to put such a system together, for now and for legacy build systems, I will use xcodebuild -derivedData to improve build systems I have to work with.

1 comment:

moai said...

Thank you! So much!! :)