Hosting Under CW
Volume Number: 12
Issue Number: 10
Column Tag: Rehosting Development Tools
Hosting Under Metrowerks 
by Farooq Butt and Drew Sarkisian, Motorola RISC Software
In an earlier article (“SPM, Be My Host”, MacTech v12, No. 6, June 1996) we
talked about hosting Motorola’s highly optimizing mcc C/C++ compiler under the
Symantec Project Manger. Since that article, the Motorola RISC Software Compilers
and Tools Group has created compiler plugins for the popular Metrowerks
CodeWarrior IDE. This article shares our experiences creating these plugins. We
hope to help others of you out there facing a similar challenge and jump-start your
efforts.
Motorola has offered highly optimizing C, C++ and FORTRAN compilers for the
MacOS since May 1995. These compilers were initially hosted only in the Macintosh
Programmer’s Workshop (MPW) environment, a UNIX-like command-line driven
shell. Even though our compilers currently generate the highest performance code in
the Mac development arena, we felt the need to provide mcc’s technology in a
friendlier wrapper than that afforded by the MPW programming environment. This
basic need was the impetus behind our efforts to first port our compiler into the SPM
(Symantec Project Manager) and subsequently to the Metrowerks CodeWarrior IDE.
For a further description of mcc and its background, please refer to our earlier
article.
Project Background
As stated earlier, our CodeWarrior port came after our Symantec port. The
grizzled UNIX-heads who had not even known what a resource-fork was prior to
porting mcc to the SPM, were quite a bit more savvy the second time around! We
decided to not only do a compiler plugin, but also a full preference panel plugin too.
This would give the paying public the ability to use the familiar Mac point-and-click
interface to send options to mcc instead of using a command-line facsimilie as in the
SPM port (the SPM port has also been enhanced with a preference panel).
Nearly all of the work that was done hosting mcc as a CodeWarrior plugin was
done at Motorola in Austin, TX. Even though Motorola was one of the very first
consumers of their CW8 plugin API, Metrowerks proved to be a supportive and agile
partner and provided invaluable technical help all along the way. As of the CW9
release of the API, we feel that Metrowerks’ documentation and examples have
progressed to the point that prospective plugin writers should not require any special
intervention from Metrowerks.
The Important Issues
We covered these major issues in our last article, but we thought it would be
valuable for new readers to re-cap the basic differences between tools that are driven
from the command-line and those driven from (Macintosh) IDEs. Some of these
differences are obvious and visible to the user of the compiler, while others are of
concern only to the engineers who develop and maintain the compiler.
Command line typed by a user . Command-line compilers accept their arguments
via a command line typed by a user or generated by a Makefile. On the Mac, these tools
are generally MPW tools that take their command lines from an MPW shell. Compilers
hosted within IDEs have visual (and more intuitive) interfaces implemented via dialog
boxes, preference panels etc.
Allocation and freeing of system resources. Compilers from UNIX (or Mac’s
MPW environment) often do a poor job of freeing all of the heap memory they allocate.
Instead, they rely on the system (or MPW shell) to reclaim all memory resources
when the compiler process terminates. This is a recipe for disaster when running
under an IDE: memory will leak until the IDE (or system) crashes. These compilers
may also have the bad habit of leaving open file descriptors lying around, causing the
IDE to run out of usable file descriptors. Simply stated: command-line based
compilation systems often assume that each executable component will be launched by a
shell and when its particular job is done, it will be cleaned up after.
Initialization of static data.. Upon each invocation of a command-line compiler,
the system loader will initialize all of the compiler’s static variables to either 0 or
pre-set values determined at compile-time. A compiler hosted under an IDE may need
to remain memory resident, and might have to explicitly re-initialize its own static
data between compiles.
ANSI C file I/O functions. Non-Macintosh compilers often use fopen(), fread(),
etc. when processing source files for compilation, producing temporary files, and
generating resultant object files. Such compilers deal exclusively with ANSI file IO
abstractions such as pointers to FILEs, etc. An IDE, on the other hand, typically uses
different mechanisms for reading/writing files. A related issue concerns how a
compiler is to locate source files and headers files. The most recent copy of a file could
be open in an IDE editor window. When the user asks for that file to be compiled, an
IDE-hosted compiler has to know that the file in question is in memory, and not on
disk, and access it accordingly.