Tag: WWDC

In case anyone hasn’t noticed, Xcode 2.1 shipped at WWDC on Monday. It includes a whole slew of new features. First and foremost is, of course, Intel support. Lots of people have said a whole lot about this so I won’t repeat it here.

The new feature that will have the most significant and immediate impact on developers’ lives is the switch from build styles to configurations.

In Xcode 2.0 and earlier, a build style was a collection of project-level settings that were overlaid on the settings for all targets in the project. For example, if you specified OTHER_CFLAGS="-DFOO=1" in a build style and OTHER_CFLAGS="-DFOO=0" in a target, the build style would take precedence when it was active and the compiler would be passed "-DFOO=0".

This was confusing: Build styles were edited by inspecting the target, and the OTHER_CFLAGS entry in the target settings showed up with a strikethrough when it was overridden in the active build style. This also caused problems for some developers who didn’t want settings from build styles overlaid on all targets in a project, and they particularly didn’t want settings from a build style in a project to override settings in targets in subprojects.

Configurations in Xcode 2.1 are just collections of settings. Settings in a target configuration override settings in the matching project configuration. Also, target configurations are by default self-contained, while project configurations default to being empty, which means by default you don’t have to worry about overriding at all. What’s more, configurations are applied by name when building subprojects — settings in the project you’re building don’t override subproject settings.

Editing build settings in Xcode 2.1 is a lot like editing build settings in Xcode 2.0 and earlier: You just select a target or the project and bring up its inspector, and build settings show up in the Build tab. You can select a configuration to edit, and you can even edit all configurations at once. This is very, very useful — often most of the settings for a target will be identical across Debug and Release configurations. The ones that aren’t show up in a mixed state.

(Did you notice I referred to Debug and Release configurations? That’s because Development and Deployment have been retired.)

You can even specify that a configuration is based on a text file of key/value pairs with the “.xcconfig” extension. So if you have collections of settings that you want to standardize on — for example, a suite of compiler error and warning flags — you can store them in files and check them into your source code control system separately from any projects. You can even copy or drag directly from the target/project inspector in Xcode and paste or drop in an xcconfig file!