Jul 97 Factory Floor
Volume Number: 13
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.