|
Log In | Not a Member? |
Contact ADC
|
Xcode 2.5 is a version of Xcode 2 that runs on both Mac OS X 10.4 (Tiger) and Mac OS X 10.5 (Leopard). Please choose Show Older Release Notes from the Help menu to see the release notes for Xcode 2.4.1, 2.4, 2.3, 2.2, 2.1, 2.0 and 1.5. The Xcode 2.5 Release Notes can also be viewed in the ADC Reference Library.
There are three improvements in this version of Xcode
Its Installer allows you to install on either a Tiger or Leopard system
When installing on Leopard, you may install in a location other than the /Xcode2.5 directory on the startup volume
When installed on Leopard, you may move the /Xcode2.5 folder in its entirety to any other location and use Xcode normally
For detailed information on the security content of this update, please visit this website: http://www.info.apple.com/kbnum/n61798
General
Using Xcode 2.5 on Tiger
Using Xcode 2.5 On Leopard Alone
Using Xcode 2.5 On Leopard Along With Xcode 3.0
Installing Custom Xcode Extensions
New User Defaults for Job Control
Other changes
Special Notes for Dedicated Network Builds
Known Issues in Xcode 2.5
Additional Documentation and Help
Supported configurations
Xcode 2.5 will run on Mac OS X 10.4 (Tiger) or Mac OS X 10.5 (Leopard) on a Macintosh with either a PowerPC or an Intel processor. It will not install or run on earlier versions of Mac OS X. Xcode supports development for Mac OS X 10.2 (Jaguar), Mac OS X 10.3 (Panther), or Mac OS X 10.4 (Tiger) (both PowerPC and Intel) using the Mac OS X SDK support.
Xcode 2.5 does not support development for Mac OS X 10.5 (Leopard) even when running on a Leopard machine. To take advantage of Leopard features, you must use the compiler and linker that are built into Xcode 3.0.
Distributed Builds (both Shared Workgroup Builds and Dedicated Network Builds) are not supported for Xcode 2.5 running on Leopard. Both varieties of Distributed Builds work when using Xcode 2.5 on Tiger to distribute to other Tiger machines, or using Xcode 3.0 on Leopard to distribute to other Leopard machines.
Project File compatibility
The project file extension and format are unchanged for Xcode 2.5 from previous versions of Xcode; any project from Xcode 2.1 or later can be opened and built with Xcode 2.5 interchangeably.
In addition, Xcode 2.5 recognizes certain project elements inserted by Xcode 3.0, so a project that has been opened and built with Xcode 3.0 can still be opened and built with Xcode 2.5 so long as it does not require specific new features of Xcode 3.0. The Project Compatibility feature of Xcode 3.0 allows you to enforce compatibility with Xcode 2.4. Projects compatible with 2.4 will work with Xcode 2.4, 2.4.1, and 2.5, and may work with Xcode 2.3, 2.2, and 2.1 if they do not use features from Xcode 2.4 or later.
Building with Xcode 2.5 on Leopard requires the use of the Mac OS X 10.4u (or earlier) SDK. Because Legacy ("Jam-based") targets cannot use SDKs, you cannot build legacy targets using Xcode 2.5 on Leopard. Upgrade all targets to Native Targets and set the SDK before building.
When installed on a Mac OS X 10.4 system, Xcode 2.5 replaces any previous version of the Xcode Tools. It removes Xcode-specific content from /System/Library/PrivateFrameworks and instead puts all Xcode-related content into the Developer directory.
When installed on a Mac OS X 10.4 system, Xcode 2.5 installs the core developer tools into the /usr/bin directory as well as in its own Developer directory, so traditional makefile development is unchanged.
When installed on a Mac OS X 10.5 system, Xcode 2.5 is placed in a folder called Xcode2.5 at the top level of the startup disk. At install time you can choose any other location and name for this directory. The Xcode 2.5 Developer Tools folder is completely self-contained; no files are installed onto a Leopard system in any other location.
When installed on a Mac OS X 10.5 system, Xcode 2.5 does not install any files into /usr/bin because its Tiger-based tools are not compatible with native development for Leopard. Xcode will find these tools automatically, but if you want to do makefile-based development for Xcode 2.5 on Leopard, you must set your PATH environment variable to specify Xcode 2.5's /usr/bin directory first in order for its tools to be used, and also ensure that you are using the 10.4u SDK so that you do not include Leopard header files or link to Leopard link libraries.
You can use Xcode 2.5 and 3.0 simultaneously on Leopard. The two versions are mutually self-contained and can operate independently. Some things to be aware of when using this configuration:
Do not open a project simultaneously in two different versions of Xcode. Remember that opening a project also implicitly opens its cross-project references, so take care when using families of related projects.
Xcode 2.5 and 3.0 have the same UTI and creator type, so when you double-click any Xcode file, LaunchServices will open it with the currently-executing version of Xcode, if any, or launch the copy of Xcode with the highest version number. For this reason, dragging and dropping files onto the Xcode icon in the Finder or Dock is a more reliable way to ensure you're using the right version of Xcode. Note that the application icon for Xcode 3.0 is different, to allow you to distinguish the two applications in the Dock.
Xcode 2.5 and 3.0 share the same preferences file; changes you make to Xcode Preferences in one version will affect the other.
Custom project templates should now be placed in the appropriate directory in the /Library/Application Support/Developer/Shared/Xcode/ directory. These will be available to both Xcode 2.5 and 3.0 on a Leopard system. Per-user templates can, as usual, be placed in the equivalent location in ~/Library.
If you use custom User Scripts with Xcode 2.4.1 or earlier, you should manually move these scripts into the /Library/Application Support/Developer/2.5/Xcode/ directory to use them with Xcode 2.5. Per-user scripts can also be placed in ~/Library/Application Support/Developer/2.5/Xcode/ in the user directory. Because Xcode 2.5 and 3.0 use different User Script mechanisms, they generally don't share user scripts.
Plug-ins, extensions, macros, and other files in /Library/Application Support/Apple/Developer Tools/ are ignored by Xcode 2.5.
When using Distributed Builds or running on a multicore or multiprocessor machine, Xcode attempts to execute as many jobs in parallel as the available CPUs can handle. It does not, however, take into account other resources, such as disk and memory capacity, so for some machines the use of multiple processors will cause a build to take more time, instead of less. Xcode has historically supported a user default, NumberOfParallelBuildSubtasks, to limit the number of simultaneous build tasks, but as this applies to both local and distributed jobs it is not useful for optimizing build time.
Xcode 2.5 supports two new user defaults to control the number of simultaneous subtasks for local and distributed builds, so distributed jobs can use more processors even if the number of local jobs must be limited due to memory or disk constraints.
NumberOfLocalBuildSubtasks controls the maximum of jobs to execute on the local processor. This functions the same as today's NumberOfParallelBuildSubtasks for all local builds, but with Distributed Builds it only constrains the number of precompiled header jobs to perform simultaneously. Because building precompiled headers can consume a very large amount of memory, machines with an imbalance of processors to main memory (e.g.a Dual Quad Xeon with 1Gb RAM) may attempt to build too many precompiled headers in parallel, resulting in swapping that causes build time to increase. Setting this default to a smaller value than the number of processors can improve build times in such circumstances.
NumberOfDistributedBuildSubtasks controls the maximum number of jobs to distribute to remote machines. This defaults to the maximum number of processors on the available remote machines; if this is too large, your local machine may spend too much time dispatching and receiving jobs and negate the benefits of distribution. Setting this to a value lower than the number of processors on available distrbution machines may make distributed builds complete more quickly, depending on your memory, disk, and network resources.
You may need to experiment with different values for these two settings according to the language of your source code, the size of your precompiled headers, the amount of memory you have, the speed of your network, and the number of distributed build machines available.
Note that these settings have no effect in Xcode 3.0.
Xcode now passes the path to the SDK in use to Rez using the -isysroot flag.
You can use the expression $(inherited) in .xcconfig files to denote the value of the build setting at the next higher level of evaluation.
Because of Mac OS X 10.4.10 and later, the value of MAC_OS_X_VERSION_ACTUAL has overflowed its allocated four-digit space. You can use the new predefined build setting MAC_OS_X_VERSION_MINOR to distinguish all versions of Mac OS X that start with 10; for example, 10.4.10 is 0410 and 10.5.0 is 0500. This build setting is available in Xcode 2.5 and later.
In general, Dedicated Network Builds have higher reliabilty in Xcode 2.5 on Tiger than in prior versions of Xcode, but there are some limitations.
To enable Dedicated Network Builds, you must restart the machine after checking the Dedicated Network Builds check box in Xcode Preferences.
A build machine configured for Dedicated Network Builds can process jobs from only one host at a time.
Building C++ or Objective C++ (whether from Xcode or the command line) will fail if the full path to the Developer folder contains any characters interpreted by the Unix shell, such as asterisk, tilde, percent, quote, single-quote, or space. Ensure that the volume name and full path to the Developer folder contains only alphanumeric characters. C and Objective-C do not have this limitation.
When running on Leopard, building for more than one architecture may fail if ZeroLink is enabled. To avoid this problem, do not enable ZeroLink for configurations that build Universal.
When running on Leopard, Xcode 2.5 cannot upgrade Xcode 1.0 (".pbxproj") projects. Renaming a project to use the ".xcode" extension will allow it to be upgraded.
When running on Leopard, Xcode 2.5's Key Bindings preferences are not shared with Xcode 3 or later, and are not imported from any version of Xcode running on Tiger. If using both Xcode 2.5 and Xcode 3 or later from the same user account, ensure that the key bindings set you use in each has the same name.
Under certain network conditions, Xcode 2.5 may hang for up to a minute at launch or when xcodebuild is run.
When predictive compilation is enabled, Xcode may occasionally fail to recompile source code that has been modified.
Under some circumstances the Xcode 2.5 uninstaller will fail to run properly. If the path to the directory where Xcode 2.5 was installed contains an embedded space in the pathname, an error message will be generated along the lines of:
$ sudo /Volumes/Developer\ Tools/Library/uninstall-devtools |
Can't exec "/Volumes/Developer": No such file or directory at ./uninstall-devtools line 162 |
The workaround is to invoke the uninstaller with the --verbose option, as follows:
$ sudo /Volumes/Developer\ Tools/Library/uninstall-devtools --verbose |
This will work properly.
Xcode can now alert you to the availability of updates to the Apple Developer Connection (ADC) reference library and help you download the new content. See the Using the ADC Reference Library documentation for more information.
The documentation window now uses SearchKit indexes when performing full-text searches. Besides improving search speed and the general quality of the set of results, full-text searches now support boolean search strings and wildcard searches among other features. See the Searching for Documentation documentation for more information.
Additional release notes for Mac OS X are located in the ADC Reference Library Release Notes. On this website, there are release notes on specific tools, such as the GCC 4 Release Notes, the GDB Release Notes.
http://developer.apple.com: Apple’s Developer Central site is the best source of official up to date technical documentation on Mac OS X as well as being the primary place to find out about developing for the Macintosh platform.
http://developer.apple.com/tools/xcode: The Xcode home page on Apple’s developer site.
There are a number of mailing lists that are great for Mac OS X and Xcode developers. For more information please go to http://lists.apple.com. There are lists on the following topics and many more:
xcode-users: This list is great for asking (and answering) questions about Xcode.
java-dev: A place for Mac Java developers to hang out.
cocoa-dev: Keep in touch with the Cocoa community.
carbon-dev: Keep in touch with the Carbon community.
fortran-dev: For Fortran development issues.
unix-porting: For developers porting standard Unix software packages.
webobjects-dev: For WebObjects development issues.
All members of the Apple Developer Connection can use the online bug reporting tool (bugreporter) to communicate issues with Apple. Please include detailed information of the issue, including the system and developer tools version information, and any relevant crash logs or console messages.
To send feedback to Apple, please use:
xcode-feedback@group.apple.com: Comments or feedback on the Xcode Tools suite.
cocoa-feedback@group.apple.com: Comments or feedback on AppKit and Cocoa.
Last updated: 2007-10-31
 |
||
|
|
|
|
| ||
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |