Jun 96 Factory Floor
- Feb 96 Factory Floor
- Mar 96 Factory Floor
- Apr 96 Factory Floor
- May 96 Factory Floor
- Jul 96 Factory Floor
- Aug 96 Factory Floor
- Sep 96 Factory Floor
- Oct 96 Factory Floor
- Nov 96 Factory Floor
- Dec 96 Factory Floor
- Jan 96 Factory Floor
Volume Number: 12
Issue Number: 6
Column Tag: From The Factory Floor
The CodeWarrior IDE 
By Dave Mark
This month, we’re going to talk to the folks responsible for the CodeWarrior IDE. By
the time you read this, Metrowerks will have shipped their ninth release of
CodeWarrior. In that time, the IDE has changed significantly. However, there is still a
lot of growing room left. This interview focuses on some of the changes that have
already taken place, and offers a glimpse into the future of the IDE.
Dave: Where do you see the IDE going from here? What kind of changes are
coming?
Berardino: The IDE has come a long way in the past two years, but we feel that a lot
remains to be done. The main goal for the near future is to improve the IDE’s
ability to handle large projects involving multiple developers. Also, with the
growth of object-oriented languages, we’ve added an object browser to the IDE
which shipped with CW/8 and will go final with CW/9 - but that’s just the first
release. Many more improvements are planned in that area.
Many complex projects involve the building of multiple final binaries, which is
usually not easily supported in a project-based development environment. We
plan to address this problem through support for intelligent nested projects,
along with support for multiple output targets from the same project. The build
system will also be improved in order to better support compiler chaining,
where one compiler’s output is passed along to another compiler before
generating a final object file (yacc is a good example of this). Source code
control will be addressed by adding integrated support for our CodeManager
system, which is the MacOS version of Microsoft’s SourceSafe.
Dan: We’re just finishing the first release of the source code browser. It’s really
helpful for navigating and editing source code, classes in particular. You can
browse the full class hierarchy, or open a separate browser on an individual
class. Also, you can see all the types, globals, constants, enums, functions,
structs and macros in your program, and jump instantly to their declarations.
By the way, the browser is driven by information generated by compilers.
We’ve documented the format of this as part of our plug-in compiler API, so
anyone who makes a drop-in compiler can support our browser.
Dave: How will nested projects work? Can you give us an example?
Berardino: Nested projects will allow users to encapsulate their files into distinct
subprojects that are automatically tracked and updated, so that when the user
issues a make from the topmost project, the build system will check to see if any
of the subprojects need updating and will build those first, updating any new
dependencies as they are created. This becomes more and more important in
today’s world of component software, where an application is made up of many
separate plug-ins. The CodeWarrior IDE is a good example of this. Right now we
have over 50 projects that are used to generate just the Macintosh-specific tools.
Currently, we use AppleScripts to automate this build. With nested projects, we
could have one master project that had as its subprojects all the tool projects,
which in turn could have subprojects which generate any libraries that the tools
need. With a single make issued at the top level, we would build all 30 or so
output files without any further user interaction.
Dave: Tell me about “multiple target” support. Will I be able to choose between
68K, PPC, or fat? Will I be able to selectively bind source files to specific
targets?
Berardino: Multiple targets is a feature that many Macintosh users have been
asking for. Today, building a MacOS application involves generating two distinct
applications from the same source base, one for 68K users and one for PPC
users, and then merging them together into a final binary. Currently the only
way to support this is through the use of two distinct projects, or to switch the
target from 68K to PPC, which will strip out the object code you just finished
compiling. What we plan to do is to have multiple targets with persistence,
where you can have many different targets, such as 68K debugging, 68K release,
PPC optimized, etc. When you switch to a different target you don’t lose all your
current compiled files. Switching back won’t force you to recompile all your
sources again. We also plan to support binding of files to a specific target, which
will allow users to have their 68K libraries ignored by the PPC target and vice
versa, or have certain files only compiled for an x86 target and ignored by
MacOS targets, which is useful for user interface-specific source code.
Dave: How will CodeManager be integrated into the IDE?
Berardino: We already support CKID resources in the editor. A future release will
have the CKID state visible from the project window, and will provide all tools
which are necessary for managing SourceSafe databases. These tools will allow
users to track different versions of their source code without having to leave the
IDE. We will also be providing a file/folder compare tool in the IDE, which will
help users to determine what changed between releases.
Dave: Do you plan to support having multiple projects open at once? What about
supporting threads in the IDE?
Berardino: Having multiple projects open at once is very useful with an IDE that
supports subprojects, because it allows users to work in two projects at once.
Full support for threads will allow users to be compiling in one project while
simultaneously editing a file in another project. With the coming of Copland and
its preemptive threads, users will see less of a performance impact from using
threads than exists with today’s cooperative threads. We are very excited by the
performance that Copland can bring to MacOS with its microkernel architecture
and fully native file system. Development tools are typically I/O-bound. A
typical compile/link cycle can spend 40-60% of its time doing file I/O, so any
improvements to the file system will translate directly into increased
compiler/linker speed. Having a fully preemptive microkernel will allow us to
add features that are impossible with the current MacOS architecture.
Dave: How will the browser change? Will the level of integration between the
browser and the rest of the environment change?
Dan: Over time, we’re planning to extend the browser in a number of ways. The
goals are to simplify the task of programming and to create more powerful tools
for analyzing large, complex programs.
One important area is to automate some of the routine aspects of object-oriented
programming. So, you’ll be able to create new classes and members and be
spared the hassle of creating new header and source files and filling in all the
boilerplate code. And the browser will handle keeping member function
declarations and bodies in sync.
Many users have asked for a graphical view of the class hierarchy, so that’s
something we plan to address. Another area is to allow browsing of dynamic as
well as static relationships in programs. We took a browser-oriented approach
with the user interface of the Metrowerks debugger. For example, you can
browse through lists of local variables, global variables, types and processes.
We’ll extend this by adding support for browsing object instances and by
supporting object-oriented breakpoints. The latter allows you to stop a program
when any method of a particular object instance is entered, or when any method
of a particular class is entered. When you are debugging an object-oriented
program you’re often thinking in terms of classes and instances, so the
environment should let you work that way.
Dave: What kind of plug-ins will be supported? Why would someone want to write
their own plug-in?
Berardino: Almost any type of plug-in can be written, but the one major
limitation in today’s CodeWarrior make system is that we can’t easily support
one plug-in’s output being fed to another plug-in. The new build system we’re
planning will allow arbitrary chaining of plug-ins, so users can more easily
support compilers (such as yacc) which generate C source files from their input
files, which could then be chained to the C/C++ compiler, which would generate
the final output file. A post-link phase is also planned, which would allow users
to write custom plug-ins that could take the final application and do post-link
processing on this. Good examples of possible post-linkers are: a tool that would
merge PEF containers; a tool which would create a fat application from two input
applications; or perhaps a tool that performed optimizations on the final
generated binary.