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.