Targets (and More!) in CodeWarrior vs. Xcode

I opened up CodeWarrior 8.3 again for the first time in a while, in order to talk about targets in CodeWarrior vs. targets in Xcode (see below).

Instant opening and editing of huge source code files! Cmd-tab, instead of the vastly more cumbersome Cmd-Opt-Up Arrow! Multiple versions of the tools on the same partition!

Ahem.

Sorry, nostalgia got the better of me. Onward….

CodeWarrior 8.3 on Tiger

CodeWarrior 8’s last update was late 2002, and I’m on Mac OS X 10.4 “Tiger,” which (if you didn’t hear) was released this year, so of course I was expecting problems.

Here are the steps I used to get something up and running:

1) In CodeWarrior’s application-wide IDE preferences, under General -> Source Trees, change the OS X Volume path from / to /Developer/SDKs/MacOSX10.2.8.sdk. Be sure to save your changes before opening any projects.

2) Open Metrowerks CodeWarrior 8.0/Metrowerks CodeWarrior/MacOS X Support/CocoaHeaders/CocoaHeaders.mcp and rebuild all targets.

3) Create a new CW project, based on the Mac OS X Cocoa Stationary.

4) Build and run/debug. Don’t close CodeWarrior.

Importing a CodeWarrior Project into Xcode

Now, I take this working CodeWarrior project over to Xcode:

1) Import the CodeWarrior project into Xcode. The Import command is under the File menu. Don’t check the “Import Global Source Trees from CodeWarrior” checkbox.

There’s no step 2)!

Oh, wait, there is. Such as copying the info from the .plc file to an Info.plist file. But my goal here is not to get the project completely functional on Xcode. There are other places to go for that, such as Apple’s online document Porting CodeWarrior Projects to Xcode.

My goal is…well, first, in the interest of not throwing away useful information, I might as well list the problems I had during the import.

Problems During Import

  • On one machine I had, the Xcode importer had problems if the project to be imported was on my Desktop. If I moved it to another partition, it imported without errors.
  • On that same (cursed?) machine, I had a problem with Xcode not knowing where CodeWarrior was. Quitting and restarting Xcode didn’t solve the problem, but it worked correctly after the machine fell asleep and was woken up (??).

As with other Xcode issues, I would say keep fiddling with it, and you’ll probably get it to work.

Target, the Concept, in CodeWarrior and Xcode

My goal, as I started to say above, is to demonstrate the difference in the concept of target between Xcode and CodeWarrior.

Make an Xcode Cocoa Application project and set it next to the CodeWarrior import.

Xcode’s non-imported version has only one target, called whatever the project was originally named. The CW version has two targets, Cocoa Debug and Cocoa Final.

CodeWarrior handles the concepts of “debug” and “release” versions of your application by giving you two completely different targets. You have to add the proper files for compilation to each of those targets, and you have to specify all the settings, such as access paths and warnings, for each as well.

In Xcode, “debug” and “release” are just considered variants of the same target. All files are specified just once, in a single target. All settings which are not debug or release-specific can be set on that target as well. Then, the debug and release-specific stuff is set in the build configuration associated with that target.

This works in Xcode because you can easily set macros outside any source code files. You don’t need a separate prefix file to set values like DEBUG for debug versus release, just set a build setting in each of your “debug” and “release” build configurations.

This didn’t work optimally in Xcode, up until 2.1, because these variants used to be built in the same location. In CodeWarrior, the result of the “debug” and “release” targets usually have different names, and different temp file locations. In Xcode? Same name, same temp file locations. So you generally had to wipe away the result of one configuration to build the other. This has been fixed in 2.1. (Though for some people the “fix” broke behavior that they depended on.)