What are your experiences porting legacy code to OS X. Would you like to use compilers other than those currently supported by XCode.
Think about an Automator script that performs:
Xcode Transition: Doing It Right
Before you migrate a project to Xcode, you can take a few steps that will save you considerable time and effort later.
Converting to Carbon
You should first convert your code to Carbon using the latest version of CodeWarrior to smooth the transition.
Keep in mind that Carbon is a set of programming interfaces that allows applications to run natively in Mac OS X. If an application uses an older operating system model and older operating system APIs that are not part of Carbon, it cannot run reliably in Mac OS X, except in emulation mode.
Transitioning to Mach-O
After converting your code to Carbon, you should do a Mach-O transition.
Mach-O is the native executable format in Mac OS X. Applications that use Mach-O format have access to all native Mac OS X APIs, such as Quartz and POSIX, and can more easily support symbolic debugging with GDB.
Individual Headers to Framework-Style Headers
One important transition in moving to Mac OS X development is the switch from individual headers to framework-style headers in your source code files. A framework is a type of bundle that packages shared resources, such as a dynamic shared library and its associated resource files, header files, and reference documentation. An umbrella framework is a framework that includes a number of related frameworks.
This means that although CodeWarrior allows for a different prefix for each module, Xcode requires the same prefix file. The information in the framework-style header should be limited to the common pieces that you can use throughout.
Precompiled Header Mechanisms
Precompiled headers are binary files that represent the compiler’s intermediate form of the headers required to compile a source file, providing faster compile times. CodeWarrior and Xcode both support this feature with Prefix Headers.
Xcode allows one Prefix Header per target. If you use more that with CodeWarrior, you need to modify your source files to include just one per target.
C++ code can take full advantage of precompiled headers for improved build speed.
Moving from MSL Libraries to Apple Standard C/C++ Libraries
CodeWarrior supplies MSL libraries to create Mach-O style executables that run on Mac OS X only. In some cases, the MSL library calls through to the Mac OS X System framework library, and in some cases it provides missing features (such as wchar_t support, not available in Mac OS X prior to Panther).
If your CodeWarrior project is already building a Mach-O style executable, you should have an easier time in moving it to Xcode. If not, you should consider converting it.
Importing Compiles Your .plc Into a plist
Any packaged Mac OS X software requires an information property list file (appropriately named Info.plist). CodeWarrior projects that create similar types of software use a .plc file to supply this information.
When you import aproject into Xcode, the importer does extract property list setting information from the CodeWarrior project, but you should check the information and make any necessary additions or modifications. If your CodeWarrior project does not have a .plc file, you need to supply all the necessary information. You can read about differences between these approaches in “The Information Property List and .plc Files,” in Moving Projects from CodeWarrior to Xcode.
There are some code differences between CodeWarrior and GCC compilers.
GCC Does Not Recognize Most CodeWarrior #Pragmas
The GCC compiler dodify settings for a project.
Enabling CodeWarrior-Style Inline ASM
GCC supports CodeWarrior-style inline asm code. To enable this support, you add the following flag to your build settings:
When you import a CodeWarrior project that uses inline asm into Xcode, this flag is not set automatically, so you will have to add it yourself.
The procedure is available in “Inline ASM,” in Moving Projects from CodeWarrior to Xcode.