---

Building Code

In CodeWarrior, you can have one or more named build targets, each of which specifies a set of files and project settings used to build an output file. The project manager keeps track of project dependencies and calls on the build system to build the current target.

With Xcode, you also define named targets, containing all the files and instructions required to create a final product. In addition, you can define different build configurations for each target, which allow you to build the target with different build settings without creating a whole new target.

The following sections describe the Xcode build system and compare various build-related features in CodeWarrior and Xcode. For additional details on building code, such as how to modify build settings, start a build, display the Build Results window, and so on, see “The Build System” in Xcode User Guide.

In this section:

Native Build System
Build Configurations
Creating Debug and Non-Debug Products
Automating the Build Process
Makefiles

Native Build System

Xcode includes a fast, accurate dependency system built into the IDE (hence “native”). While Xcode fully supports legacy Project Builder projects that use a JAM-based build system, all new projects and targets—including targets imported from CodeWarrior projects—use the native build system.

Native targets have certain advantages over JAM targets. Because the dependency checking is done in the IDE itself, it is faster, which means that your builds start faster. In addition, many Xcode features, including Zero Link, Fix and Continue, Distributed Builds, and SDK Support, are only implemented for native targets.

Native targets use inspector windows for viewing and editing target settings, while JAM targets use an older-style Target Settings window. JAM targets are represented in the Xcode user interface by the traditional bull’s-eye icon, while the icon for a native target varies according to the product type—for example, applications are represented by a stylized “A” icon.

Build Configurations

A build configuration is a variation on a target that lets you build a target using different build settings without creating a whole new target. If you need to create products that differ only in their build settings, you might create one target with several build configuration. If you need to create products that differ in other types of settings (such as build phases or information property list entries), you should create separate targets for each.

The list of build configuration names is defined at the project level. To add or remove build configurations, select the project source group in the project window, click the Info button to open an inspector window, and select the Configurations pane, which is shown in Figure 1-6. By default, new projects created in Xcode contain both Debug and Release build configurations, described below. Projects you import from CodeWarrior have a single build configuration, named Imported CodeWarrior Settings.

To add a build configuration to a project, select an existing build configuration and copy it.

Although build configuration names are defined at the project level, each target in the project, and the project itself, can define a different set of build settings for a build configuration. You edit the build settings in a build configuration in the Build pane of the target or project inspector. In this pane, select the build configuration you want to edit in the Configuration menu, then add or delete settings and insert or modify values in the list below the menu. You use the minus and plus buttons at the bottom of the list to add or delete settings.

To select the current build configuration, use the Active Build Configuration pop-up menu in the toolbar of the project or Build Results window or choose Set Active Build Configuration.

Creating Debug and Non-Debug Products

In Xcode, Debug and Release build configurations typically take the place of CodeWarrior’s Debug and Final targets, respectively. When you create a new project, by default the project contains these two build configurations. You are free to modify their definitions at the target or project levels, or to add other build configurations. By default, the Debug build configuration produces debug symbols and turns off code optimization, while the Release build configuration does the opposite.

As mentioned in the previous section, projects imported from CodeWarrior contain a single build configuration, called Imported CodeWarrior Settings, which contains the target settings brought over from your CodeWarrior targets. You can easily create Debug and Release build configurations by duplicating the Imported CodeWarrior Settings configuration and customizing each of the new Debug and Release configurations with the appropriate settings.

In both CodeWarrior and Xcode, you can define a common prefix file that includes all the headers needed by a project to create debug or non-debug products. You can then define separate headers that set required preprocessor definitions (for example, #define debug 1), then include the appropriate header into the prefix file, depending on which type of product you want to build.

In CodeWarrior, this requires separate prefix files because the only way to set a macro is with a #define statement in a file (you can’t set values on a command line).

In Xcode, you can take another approach. You can have one common prefix file for all targets. You can then define preprocessor options in the target settings. This allows you, for example, to define a master debug flag you can test for anywhere in your code. Since it’s part of the target settings, the prefix file will be precompiled differently, depending on the target settings for the product.

In fact, it’s recommended that you delete any redundant targets and move the differentiating flags from the prefix headers to the appropriate build configuration of the primary target. The targets with the fewest settings are the best candidates to replace with a build configuration.

Automating the Build Process

CodeWarrior provides a substantial AppleScript dictionary, with terminology that allows some automation of the build process.

Xcode also has a substantial scripting dictionary, and provides AppleScript terminology for controlling many aspects of the build process. To examine the Xcode terminology, you can:

• Drag the Xcode application icon onto Script Editor in the Finder.

• Choose File > Open Dictionary in Xcode

• Choose File > Open Dictionary in Script Editor

You’ll find classes such as bookmark, breakpoint, source directory, and target dependency, along with events such as build and clean, to name just a few.

You can also call the xcodebuild tool from a shell window or a script to build a project. The xcodebuild tool reads your project file and builds it just as if you had used the Build command from within Xcode, although there are some differences you should read about in Xcode User Guide.

In addition, you can use the osascript and osaexecute commands to run AppleScript scripts from a shell window or shell script. These commands can target Xcode or any other scriptable application. You can use the Terminal application, available in /Applications/Utilities, to open shell windows, execute shell scripts, and so on.

Finally, you can use AppleScript’s do shell script command to launch the xcodebuild command-line tool from an AppleScript script. However, if you’re writing an AppleScript script anyway, it probably makes more sense to use the Xcode scripting terminology.

Makefiles

CodeWarrior has a Makefile Importer wizard to import makefiles.

The Xcode project importer does not import makefiles, and the IDE has no automated support for setting up a project to follow the rules in a makefile. However, it is often the case that developers don’t necessarily want to convert a makefile into a project, they would just like to use the makefile with a project. Xcode supports that goal with the external target.

An external target is a target that Xcode doesn’t maintain build rules for. For all other targets, Xcode stores information on how its product should be built and installed. As you add and remove files, Xcode keeps track of how to compile them for you. For a legacy target, you have to maintain that information yourself, usually by creating your own build file.

You add an external target by choosing Project > New Target and selecting External Target.

---