There have been few changes in the Build System so your Xcode 2.4.x projects should build the same as they did on Tiger (excepting, of course, the change from Tiger APIs to Leopard). Most of the changes in building are to support building Objective C 2.0 and 64-bit.
New Architectures sheet for 32- and 64-bit building
The “PowerPC / Intel” Architectures checkboxes have been replaced with “32-bit / 64-bit” checkboxes. Both settings are explicitly Universal. If you want an Architectures setting that is different from the ones provided by the checkboxes, select the Architectures line and press Tab to enter the Value column of the Architectures setting to edit your architecture list manually. The checkboxes transform hardcoded architecture settings (e.g. ppc or i386) into sets of hardcoded values (e.g. ppc64 x86_64). If the Architectures build setting contains $(NATIVE_ARCH), the checkboxes transform it into a build setting that is useful for debug builds:
$(NATIVE_ARCH_32_BIT) The 32-bit version of the build machine’s architecture. This is useful for non-64-bit-aware code.
$(NATIVE_ARCH_64_BIT) The 64-bit version of the build machine’s architecture. This is useful for 64-bit-only code.
$(NATIVE_ARCH_ACTUAL) The actual build machine’s architecture. This is useful for building “best thin for this machine.”
Per-Architecture Build Settings
The new Build Settings editor (available for both targets and projects) supports per-architecture entries for build settings that affect compilation and code generation. By selecting a build setting and choosing "Add Per-Architecture Setting" from the Action (gear) popup, you can specify different values for a setting for each architecture. If you don't specify a per-architecture setting for a given architecture, the "base" value of that build setting is used.
You can now specify per-architecture build settings in .xcconfig files. The syntax to define an architecture-specific setting is:
SETTING_NAME[arch=arch_name] = some_value
where arch_name is a valid architecture name as you would enter in the ARCHS build setting
New and Removed Build Settings
There are new predefined build settings that provide the major and minor versions of Xcode and Mac OS X at build time. These are in a format compatible with the Availability Macros so they can be passed down to your sources in Preprocessor Macros if desired. See the Build Settings Release Notes for details.
The Objective-C Garbage Collection setting enables compiling and linking Objective-C code for automatic garbage collection. It has three states: Unsupported disables garbage collection; Required (-fobjc-gc-only) will create an executable that runs only on Mac OS X 10.5 and later and will always run garbage collected; and Supported (-fobjc-gc) will create an executable that can run either garbage collected or not, depending on how the user chooses to launch it or, in the case of libraries and frameworks, whether the invoking application is using garbage collection.
The Enable Supplemental SSE3 Instructions build setting now sets the -mssse3 flag in gcc 4.0.
The Treat Missing Function Prototypes as Errors build setting now sets the -Werror-implicit-function-declaration flag in gcc 4.0 for C and Objective-C only.
The Order File build setting now sets the -order_file parameter of the linker. Its value should be a path to a file relative to the project folder; that file should contain the newline-separated mangled names of functions in the linked executable, in order of call frequency. Order files help increase locality of reference and reduce swapping.
In Xcode 3.0, the Zero Link build setting is ignored and has no effect. It still appears in the user interface and is preserved for backwards compatibility with Xcode 2.5 and earlier, but all executables are always fully linked in Xcode 3.0.
In Xcode 3.0, the Essential Symbols feature for STABS-based debugging has been removed, and its build setting is ignored.
Composite SDKs
You can now specify multiple SDKs; for example, a system SDK, a QuickTime SDK, and the SDK for a third-party library or framework. To do this, set the Base SDK Path build setting to a system SDK and set the Additional SDKs build setting to the list of additional SDKs to composite. At build time Xcode will create a composite SDK and cache it in a common location; all projects that use that combination will share the one composite SDKs. This allows you, for example, to use libraries provided by third parties when building against a system SDK.
Parallel Target Builds
A checkbox in the Project Inspector allows all aggregate targets in the project to build their dependent targets in parallel when possible. This means that you can build a short command-line tool while preprocessing your header files for your main application. This is especially useful on multiprocessor machines and while using Distributed Network Builds or distcc.
Note: Using parallel target builds may reveal implicit dependencies that have been masked by the serial building of targets. Turning on parallel target builds may result in intermittent and hard-to-reproduce build failures due to one target needing the output of another that has not yet been built. Inspect your project carefully and ensure that each target has its Direct Dependents set correctly before enabling Parallel Target builds.
Two- and Three-Way Unit Tests with Garbage Collection
Unit Tests now run as many architectures as possible on the build machine. Unit tests on Intel will attempt to run the 32-bit PowerPC unit tests in Rosetta, and tests on 64-bit machines will run both 64-bit and 32-bit architectures. Unit Tests can now be run on garbage-collected Objective-C code.
Run Script Build Phase
You can check a check box in the Run Script build phase to suppress the output of environment variables in the build log.