CDT 4.0: more features for embedded development

April 01, 2007

Story

CDT 4.0: more features for embedded development

2006 was a landmark year for the Eclipse C/C++ Development Tooling (CDT) environment, with growth in almost every area of the project. Currently, deve...

2006 was a landmark year for the Eclipse C/C++ Development Tooling (CDT) environment, with growth in almost every area of the project. Currently, developers download the CDT more than 85,000 times a month (up from 60,000 earlier in 2006), and more than a dozen committers are working on the next CDT release. Meanwhile, numerous tool vendors now redistribute Eclipse and the CDT with their product offerings, especially in the embedded market where the CDT has become the de facto standard development environment.

Editor’s note: I was honored to represent Embedded Computing Design on the judge’s panel for the Eclipse Community Awards 2007 "Best Commercial Developer Tool". Congratulations to Doug and his teammates at QNX for winning with the Momentics IDE. – Don Dingee

2006 was a landmark year for the Eclipse C/C++ Development Tooling (CDT) environment, with growth in almost every area of the project. Currently, developers download the CDT more than 85,000 times a month (up from 60,000 earlier in 2006), and more than a dozen committers are working on the next CDT release. Meanwhile, numerous tool vendors now redistribute Eclipse and the CDT with their product offerings, especially in the embedded market where the CDT has become the de facto standard development environment.

What’s in the CDT

The CDT focuses mainly on the edit, build, and debug cycle of software development. Its main objective is to improve the productivity of programmers writing code in C and C++ while leveraging the high-quality tool chains developers already use for building and debugging. Initially, the CDT project focused on developers who use the GNU tool chain, including gcc and gdb, which is by far the most popular tool set in the open source community. However, the CDT project now supports other environments as well, either directly or through CDT-based environments offered by commercial vendors.

The CDT follows the same user interface and project resource structure as other Eclipse-based development environments. The user interface comprises a collection of views and editors that appear as tabbed sections of the Eclipse window. The views show a variety of information about the project, and the editors allow developers to change files in the project. The views can be organized into pages called perspectives, which customize the layout of views for various purposes, such as edit and debug. Users can also adjust and save perspectives for their own specific needs. Figure 1 shows the C/C++ perspective.

Figure 1: C/C++ perspective


21

 

Projects in Eclipse are the top-level resource users work with. Typically, a project maps to a root directory in the user’s file system. Every file that resides in that directory and its subdirectories recursively become accessible to the Eclipse plug-ins. Eclipse also provides mechanisms to link other files and directories into the project structure, but does not offer a general mechanism to exclude files.

The Eclipse platform provides management for files and projects. The CDT extends this management to differentiate source files, object files, and other file types; it also provides a structured representation of file contents. Using this representation, the CDT populates both the Outline View, which shows a table of contents in the current file, and the C/C++ Project View, which shows a table of contents in available projects.

The CDT core also maintains a database of symbols across each project. This database, called an index, allows a number of features to provide source code analysis and navigation. For example, the user can select a function name in the source code and do a search to find all references to that function. The user can then invoke the rename refactoring feature to change the name of that function across the entire project.

The CDT editor offers many productivity features developers would expect in an advanced Integrated Development Environment (IDE). The biggest productivity enhancer is the content assist feature, which uses information from CDT’s built-in parser to provide valid code completions, given the context that currently contains the cursor. The editor also provides code coloring, which differentiates between keywords and identifiers to enhance code readability, and bracket matching and automatic tabbing, which make complex code structures easier to enter.

The CDT also contains the following two build systems:

  • Standard Build: Reuses the user’s existing build infrastructure. This feature is especially important for project teams that have invested heavily in conventional make files to ensure quality, reproducible builds.
  • Managed Build: Allows tool vendors to provide advanced user interfaces for setting compile and link options; it also invokes builds automatically. Managed Build is useful for new projects and for users who would rather spend time writing source code than creating build files.

The CDT debug perspective provides visualization of the debug session (see Figure 2). A native debugger such as gdb handles the nuts and bolts of executing the application, setting breakpoints, and extracting variable values. Table 1 summarizes the visualizations the debug perspective offers.

This View

Displays

Debug

The current debug sessions and the threads and stack frames for the applications under debug

Variables

Variable values for the current stack frame

Register

Current values of the CPU registers

Memory

Binary contents of memory

Disassembly

Assembly code for the instructions at the current execution location

Table 1

Figure 2: The CDT debug perspective provides visualization of the debug session


22

 

What’s coming in CDT 4.0

CDT 4.0 is scheduled for release this June. With the great influx of contributors to the CDT, the new release will introduce several exciting features that improve the user experience, enhance productivity, and offer even greater scalability. Features under development include:

  • Internal Builder: Improves build performance by removing the need to process make files. To determine which files a build must process, the Internal Builder uses Eclipse’s ability to track file changes and uses interfile dependency information stored in the CDT source index. The builder can parallelize compilers to deliver faster build times on multicore machines.
  • Support for prebuilt index information: To further boost indexing performance, the CDT indexer will allow Software Development Kit (SDK) vendors, including major operating systems vendors, to prebuild the index information for the header files provided by the SDK. The indexer can then integrate this information with the index of the user’s code, eliminating the need to parse the SDK header files in the user’s environment.
  • Enhanced index information: The CDT team has enhanced the captured index information to enable new navigation

    and source code analysis views. The Call Hierarchy View (Figure 3) allows navigation between functions and the functions that they call or are called by. The Include Hierarchy View allows navigation between files based on inclusion relationships, and the Type Hierarchy View can navigate between C++ classes based on inheritance relationships.

     

    Figure 3: Call Hierarchy View


    23

     

     

  • Support for Windows SDK: Recently, Microsoft has pro-vided its compilers as a free download for its Windows SDK. CDT 4.0 will include build and debug support to let these tools work with CDT projects. As a result, developers will no longer need to use the GNU tools on Windows, which have been problematic because of their need for an emulation environment, such as cygwin, or because of incomplete SDK support, such as mingw. This build and debug support will also open the door for Visual Studio users to migrate their projects to the CDT in the future.
  • Framework for project generation: Many IDEs that target specific platforms can generate skeletal projects for various project types. For example, a project for a desktop GUI application can generate enough source code to get the framework running and displaying a window on the screen. This boilerplate code gives the developer a head start when building the project. CDT 4.0 will provide the framework for such project generation.

CDT 4.0 will be a landmark release for the CDT. Besides allowing the CDT team to firm up APIs, the release introduces new functionality that makes the CDT a compelling environment for all developers building C/C++ applications, regardless of which platform they target.

 
 

175 Terence Matthews Crescent

Ottawa, Ontario  •  Canada, K2M 1W8

613-591-0931  •  [email protected]  •  www.qnx.com

 

Doug Schaefer (QNX Software Systems)