Volume Number: 13 (1997)
Issue Number: 7
Column Tag: From The Factory Floor

The CodeWarrior IDE Team

by Dave Mark, ©1997 by Metrowerks, Inc., all rights reserved.

This month's interview is with the folks responsible for the latest rev of the CodeWarrior IDE. The members of the IDE team: Dan Podwall (technical lead), Kevin Bell, Matt Henderson, Glenn Meter, and Rob Vaterlaus.

Dave: I'm very excited about the release of version 2.0 of the CodeWarrior IDE. What are some of the new features?

Dan: The primary new feature is a ground-up rewrite of the project manager. We gave the old code a decent burial and then started from scratch. We've learned a lot in the four years since CodeWarrior DR1 shipped and had a long list of user requests to address.

The project manager can now build multiple executable files from a single project. This can be variations on a single application, such as 68K and PowerPC versions. Or it could be anything else CodeWarrior supports, such as libraries, code resources, or shared libraries.

A project can also link to other project files, and build those subprojects during make. And of course you can have more than one project open at a time. It's very flexible.

The build system is now threaded and can handle the requirements of C++, Java, and Pascal in a very general way.

We were very concerned about not slowing down builds with all these new features. In fact, the new IDE is faster than before. In our tests, builds are usually around 30% faster. Initial builds, where the IDE has to search for include files, are up to twice as fast as in 1.7.

The project window now has three different views on the project to accommodate the increased power. There are now optional toolbars in the project, editor, and browser windows, and there's a whizzy new interface for customizing them. Keyboard shortcuts are also customizable via the Key Bindings preference panel.

Dave: What impact will the new threaded execution have on the user?

Dan: The main benefit is that you can do other things in the IDE while a make is in progress, including editing, browsing, checkin/checkout and multi-file search. So if you get compile errors during a make, you can start fixing them while the rest of your project is still compiling.

We use Apple's Thread Manager to run the build in a separate thread from the user interface. We're planning to thread other features in the future, such as version control and multi-file search. Not only does this make for a more responsive user interface, but we'll be ready to take advantage of modern operating systems like Rhapsody as well as multiprocessing hardware.

Glenn: To give some examples of how threads work together, let's look closer at what happens during a build. Under the old IDEs, all compiling and UI happened on the same thread. So, there was not much you could do during a build but wait for it to finish. Under the 2.0 IDE, as Dan pointed out, builds happen on a different thread than the UI. This means that you can still open files, use the browser, perform searches, and even edit files during a build. As the project state is changed during the build, messages are sent from the build thread to the other threads to let them know about the change. When the UI thread next gets a slice of time it will read its messages and update the project window and browser windows, for example.

Dave: With multiple targets per project, will I be able to build fat binaries? How about separate debug and release versions of my program from a single project?

Glenn: In the 2.0 IDE, each "target" matches what used to be a 1.7.x "project". Each target includes a file list, segmentation or link order, and preferences to build an application or library. Before 2.0, to build a fat application you would usually have two projects: one to build the 68K app and another that would build the PowerPC code and include the 68K app to leave a fat application. This meant that whenever you needed to update your application, you'd have to be keep the two projects in sync. In the 2.0 world, the same thing can be done within a single project. The KillerApp.u project can have one target to build the 68K app and another to build the PowerPC code and create the fat application. Maintaining the project is easier since we can now help you add or remove files from both targets at once. You'll still have to set preferences on a target by target basis, but that will be improved in a later release.

Once you've got related targets in the same project file, you can use target dependencies to make your life even easier. For example, if you have a "Killer Engine" shared library that is used by the Killer application, you can set the application target to depend on the shared library target and to link against its output. Then, whenever the application is built the shared library will automatically be brought up to date. Also, if the name of the shared library is changed, the name will also get changed in the application's file list.

Two new linkers are included in the 2.0 IDE to support working with multiple targets. The "MacOS Merge" linker can be used to merge code and resources into a single file. So, you could also build separate 68K debug and release targets, and use a third target with the merge linker to build the fat application. The other new linker, the "None" linker, actually doesn't generate an output file. It can be used to create "build-only" targets to automate building a set of targets without scripts. For example, you could add a "Build All" target that depends on all other targets and uses the "None" linker. When the "Build All" target is built, all of the other targets will be brought up-to-date without having to leave a dummy output file. This is especially useful when generating groups of applications, libraries, or plugins.

Matt: Targets are managed from the targets page in the project window. From the targets page, you can create new targets that are either empty or identical to some other target in the project. Once you've created a new target, double-clicking it will allow you to edit its settings. This is an important difference between CodeWarrior 1.x and 2.0. Language, codegen, and all the other stuff that was configured with Project Settings dialog in 1.x are now targets settings, so each target in a 2.0 project can be configured however you like.

Building debug, release, 68K, and PowerPC versions of your program is mostly a matter of adding new targets to your project. When you convert a project from CodeWarrior 1.x, it will start out with one target that's configured exactly the same as the project you converted. So if you converted a PowerPC project configured for debugging and wanted to be able to build a release version of your app, you would create a new target using the "Clone existing target" option. This produces a new target identical to the first, so all that would be left for you to do would be to edit the new target's settings so they're configured for shipping instead of debugging. Likewise, to create a 68K target, you just clone an existing target and change the new target to use the 68K linker.

It's easy to set up a target to build a fat app as well. Simply drag a 68K and a PowerPC target under the target that you want to be fat, and a target dependency will be set up so that the 68K and PowerPC targets will be built whenever the fat target is built. You'll also have to turn on the "link output" flag for your 68K and PPC subtargets by clicking in the Link column (which has the chain link icon at top). The "link output" flag tells the IDE to link the output file of a subtarget into the output file of the main target.

Figure 1. The CodeWarrior 2.0 IDE supports multiple targets within the same project.

Aside from different settings, targets can contain different files. Obviously, you wouldn't want to include a PowerPC-specific library in a 68K target. We've introduced a new feature, the Project Inspector, to allow you to examine and change which targets contain the files in your project. The Inspector always "inspects" whichever files are currently selected in the Files view of the project window. So, to move a PowerPC-specific library out of a 68K target, you would simply select the library, choose the "Project Inspector" command from the Windows menu, uncheck the checkbox for the 68K target, and the press the "Apply" button to save the change. Once the change has been applied, the library will no longer be a part of your 68K target. The Inspector works on all selected items, so if you have several files you need to inspect, use command- or shift-click to select them all at once.

Figure 2. The CodeWarrior Project Inspector.

Dave: Tell me about nested projects. Can I build a shared library as a subproject within an app that depends on the shared library in order to run?

Rob: With 2.0 you can include another project in a target in much the same way you include normal source files in a target. You can select which of the targets of the subproject you want to have built when you build the main target. You can also set whether or not the main target links against the subproject target. You would set this flag when the subproject is generating a shared or static library.

In many cases the same objective can be achieved using either multiple targets or subprojects. Multiple targets are generally preferred when you have different versions of the same code (e.g. PowerPC & 68K, Debug & Release, different localized versions) and you want to build them in various combinations.

Subprojects are nice when you have a library that is shared among many projects and you want to only have to build it once. For example, many of our projects have subprojects for PowerPlant and/or MSL. The subproject has multiple targets for PowerPC & 68K, Debug & Release. Each target in the main project is set to build and link against the corresponding target in the subproject (e.g. the PPC Debug target in the main project builds and links against the PPC Debug target of the PowerPlant subproject). When changes are made to the library code the subproject will only get rebuilt the first time.

Another situation where subprojects would be preferred over using multiple targets is if you had a product that used a plugin architecture (e.g. Photoshop, AfterDark, or CodeWarrior). You could have one giant project with a target for each plugin and a master build target that had a subtarget for each of the plugin targets. The drawback to structuring the project that way would be that if someone was just doing development on a single plugin they would still need to be working with a project that included the entire source code base which would be unwieldy.

A better way to organize the projects would be to have individual projects for each of the plugins and then have a master project that included all the plugin projects as subprojects. That way it would be more convenient to work on individual plugins, but you could still do a complete build of the entire product in a single make of the master project.

Dave: Must I rebuild all my projects to take advantage of this new architecture?

Kevin: The 2.0 IDE uses a new project format. You can convert your old projects using the Project Converter that comes with the new IDE. When converting, you have two options: you can merge multiple 1.7 projects into a single multi-target 2.0 project, or convert projects individually. Converting projects individually will create single target 2.0 projects which work the same as the original projects. Merging 1.7 projects allows you to take advantage of new 2.0 features. For example, if you have two 1.7 projects which create 68K and PowerPC versions of your application, you can merge these together with the converter to get one 2.0 project which has 68K and PowerPC targets. If you want to build a fat version of your app, you can create a third target which uses the merge linker to combine the outputs of the 68K and PowerPC targets. To avoid getting lots of duplicate resource warnings you'll probably want to move the resources to a separate target.

Dave: What's the story behind the new, configurable toolbars?

Kevin: The IDE now has user configurable toolbars in the editor, project, and browser windows in addition to the floating toolbar. You configure the toolbars by dragging command buttons, popups, and other elements from a new element list window. One of the biggest problems I had with the 1.7 toolbar was that you almost had to leave it visible because that's where the IDE reported all status information during builds, file searching, and other operations. In the 2.0 IDE, this status information is shown in other places so you can hide the toolbars without missing out on important information.

Figure 3. The Toolbar Element list, used to configure your toolbars.

Dave: Can you tell me about the Visual Source Safe plugin?

Rob: When version control is enabled in the IDE, an extra Version Control System (VCS) menu is added to the menu bar. The menu includes commands for all the common VCS commands like Get, Check In, and Check Out. There are recursive variants of all the commands so you can iterate over entire directory trees. The commands can be used from the editor and browser or with the selection in the project window.

The 2.0 IDE supports version control through a plugin interface, so we can support many different version control systems. The plugin API defines abstract VCS operations; a plugin implements these operations for a specific version control system. Our CodeManager product includes a plugin that lets you access Source Safe databases. Several people have come out with shareware plugins that let you use Projector databases and we are working with other VCS vendors to help them develop plugins for their products.

Some of the improvements we've made in the IDE really help out with using source control with project files. In 1.7 the project contains all the object code, dependency info, etc., so you need to make the project file writable just to be able to open and build it. In 2.0 the project file only contains the structural information about the project: the list of source files, subtargets, and settings for each target. All the data generated during a build is stored in a separate per-target data file. This means you can open and build projects without having to check them out. You only need to checkout the project when you add new source files, change the settings, etc.

When you get a new version of a project from the database, if any files have been added or deleted, the IDE will synchronize the target data with the new project file to figure out which files are new and need to be compiled. If the compiler settings haven't changed, you will not need to recompile any of the files that are unchanged from the old version of the project.

Another nice improvement is that we store the VCS settings in a separate per-project settings file so each user can configure VCS with their user name, password, and local root that won't get replaced when they get a new version of the project from the database.

Dave: Any other features you'd like to mention?

Kevin: The keyboard equivalents for IDE menu commands and editor actions are now customizable via a new preference panel. Any key combinations can be used, and emacs-like prefix keys are supported. Each command can be bound to two keys, so for example, emacs-addicts can bind control-x control-s to save and the standard command-s would still work.

Matt: One of the most requested new features is that you can now have multiple projects open at the same time. Perhaps the most obvious change, though, is that the project window has a completely new look - it's now divided into separate pages. The Files page contains the hierarchical list of all the files in the project. This list is for you to organize your files however you want. You can create as many levels of nested groups as you like in the Files page, and the order of files doesn't affect the way your project builds. The Targets page is, of course, where you create and configure the targets in your project. This page has a hierarchical list of your project's targets and their dependencies and subprojects. You'll also see either the Segments page for 68K targets or the Link Order page for PowerPC and Java targets. The Segments page lists the code segments in a 68K target and the files that they contain. This page works like the CodeWarrior 1.x project window. The Link Order page lists all the files in PowerPC target in the order that the files will be linked into your program. This list is flat since PowerPC executables are not segmented.

Also new is that it's now possible to drag things out of the project window. Files dragged out of the project can be dropped into all sorts of cool places. You can drop files onto applications in the Finder, you can drop files into the trash to remove them from the project, you can select a group of files and drop them into the multi-file search list in the Find dialog, or you can drag files from one project and drop them into another.