How to Use Eclipse for C and C++ Development

The Eclipse framework is not a single entity. It is built up from many smaller pieces all working together called plugins to provide not only an integrated environment but one that is highly modifiable and extensible. This extensibility is accomplished not only via connection or interaction with existing add-on plugins but in the ability for just about anyone with a modicum of development experience to add their own plugins in a relatively short amount of time.

Gone are the days when an Integrated Development Environment (IDE) vendor would need a large group of developers just to design and code the numerous windows, buttons and widgets necessary to field a professional IDE. Eclipse forms the graphical backbone for these IDEs across a wide variety of desktop operating systems freeing up a vendors programmers to work on the core competencies of the company rather than just the vehicle for user display and interaction.

In its earliest literature Eclipse billed itself as "An IDE for everything and nothing". Eclipse's mission is now defined as "Eclipse is an open source community whose projects are focused on providing an extensible development platform and application frameworks for building software". Coming as it did in the very beginning of the Web-based development approach to open source software, Eclipse is heavily dependent on such new online capabilities as Wiki thru its Eclipsepedia .

An EPIC event for Eclipse
A fairly new addition to the ranks was originally started by Genuitec, Innopract and Instantiations. called Eclipse Plugin Central or EPIC. EPIC was recently formalized and accepted by the Eclipse Foundation. EPIC is defined as offering "the Eclipse community a convenient, information-rich portal that helps software developers find open source and commercial Eclipse plugins, tools, and products that enhance the entire Java software development life-cycle."

EPIC is now part of the eclipse.org web site and bills itself as "the community portal for Eclipse-based products and plugins". Joining the eclipse.org fold has been a fairly straightforward process for the EPIC designers as the only real change seen by users is that they are now governed by the same terms of use and privacy policy of the core eclipse.org site. The EPIC site is a useful place for monitors of Eclipse trends as the site lists such information as News and Headlines, a Plugin Directory and New Product Announcements. They also provide plugin ratings based on Activity as well as Top-Rated and New/Updated sections.

In the parlance of the open source community the EPL is not considered viral i.e. it doesn't of and by itself "infect" other pieces of software forcing plugins (and their vendor companies) to be completely open. Vendors are free to make their own decisions about whether or not to make their product source code openly available to their customers.

There seems to be three mindsets when it comes to considering Eclipse as an underlying framework for any desktop application, not just embedded operating system IDEs. The first mindset is the most exclusionary; to ignore or otherwise refuse to utilize Eclipse in any way in an IDE or application project. This occurs most often in vendors who have a fairly complete proprietary system that has already been in use for quite some time.

This represents a fairly large monetary investment for these companies so they are naturally reluctant to hand over the reins of certain product areas to an open environment such as Eclipse. The problem with this approach is that it does not typically allow the user to mix-and-match best-of-class tools from other vendors in a single environment instead locking the user into a fairly exclusionary proprietary approach.

The far more dominant approach to using Eclipse is that of proprietary vendors who use Eclipse as their graphical desktop backbone, in a sense piggy-backing on top of an open environment (Eclipse) to provide their own still-proprietary functionality. Often vendors with this mindset will reduce or otherwise modify the Eclipse environment thereby replacing certain Eclipse functionality with their own proprietary solutions for specific types of application usage or development.

In this case, the vendor is free to utilize the Eclipse framework and its open nature while reserving the most critical path functionality for a proprietary solution. In some extreme cases however what is left may not resemble the core of Eclipse as much as their customers might wish it to.

A still smaller group of companies, usually with a much smaller level of engineering investment, will endeavor to retain all or most of the same open source philosophy employed by the Eclipse Foundation. These companies usually ship their products as complete source code or source-code-plus-binary solutions.

The advantage to this approach is two-fold. First these vendors will usually have a smaller customer support workload as the customers themselves can often address bugs or create workarounds without requiring outside assistance from the vendor. Customers with this ability also may develop an increased sense of ownership in the product and a willingness to contribute to its continued success.

Secondly, these smaller vendors often enjoy a healthy level of professional services work in designing and delivering modifications not only to their own core product lines but often to the Eclipse framework as well. All of these add up to a greater level of customer interaction and control of the application or development environment while ensuring a steady stream of product improvements and enhancements to the vendor.

Eating Your Own Dog Food
In the software development industry, there is a saying among IDE developers called "Eating Your Own Dog Food". This refers to the fact that many developers of IDEs don't actually use their IDEs either to develop their IDE product or as a development environment for other products. Instead many IDE developers use command-line methods to construct the interface they expect users to use. As a result, since the developers of the IDE are not, in fact, users of the IDE, there is a loss of understanding or empathy for the user experience. They don't eat their own dog food.

If a developer was forced to eat something (like dog food) that he could design then the dog food would almost by definition be the best tasting dog food around. What does this have to do with Eclipse? Eclipse eats its own dog food. To develop plugins to run in Eclipse, you use Eclipse and its Plugin Development Environment (PDE) plugins.

Within the PDE the developer can create a new plugin and can then run and debug it from within Eclipse using what is called the Runtime Workspace. The Runtime Workspace is a directory just like the regular Workspace directory that is persistent and works as if it was a real Workspace for the plugin under test. When testing, Eclipse actually launches a second version of itself that acts as if it was a regular Eclipse installation with the new plugin already installed. Developers see and do exactly what the user would see and do.

Armed with the PDE, plugin developers can develop for Eclipse while working in Eclipse. This means that literally every Eclipse developer is also a user with a user's perspective of the environment. In this way, the Eclipse community stays fully in touch with its users with an accompanying willingness (and self-interest) not only to test new functionality but to participate in bug fixes and updates. The PDE is constantly under revision to accommodate the needs of an ever-widening group of Java developers working in both the desktop application and embedded spaces.

To further extend the development environment, Sample Projects, Project Managers and Wizards (see Figure 1, below) were created to allow for fast and easy initial development of plugins. Indeed, in a matter of minutes a developer can mock up a complete plugin solution, test it and deploy it to its .jar file. In this way, the act of creation of a plugin in and of itself resolves a host of deployment issues before any new code is even written.

Figure 1: Plugin Wizard

The need for a higher level deployment mechanism than simply plugins was also needed. What if a single vendor wanted to ship more than one plugin and didn't want to go through the process of extracting each plugin to its own deliverable and then deploying an entire group of them? Developers needed a simpler mechanism for developing and deploying a multiple-plugin solution.

Eclipse Features were created to address this need. Eclipse Features have their own manifest file called feature.xml and this file defines the entire set of plugins to be fielded as part of that Feature. Vendors could now deploy the Feature with its underlying plugins rather than each plugin separately. In addition, Features allow for a better branding strategy whereby a vendor can supply more fields such as opening banners and vendor-specific information that was difficult to encapsulate at the plugin level.

Also as an outgrowth of all the discussion of larger levels of product deployment and along with a growing need for live or web-based methods for upgrading products after deployment in the field, the idea arose to create an online method of updating or uploading the latest revisions of a product to the installed customer base. Even the Eclipse environment itself would benefit from a solution to this problem as now users would not have to download new updates and then port all their development work from one version of Eclipse to the next. The solution for this problem is known as Update Sites.

With Update Sites, Eclipse users can connect to and download new revisions of Eclipse and most if not all of the most recent add-on plugins directly from a Web-based interface. This was not just a download method but a way for dynamically updating the environment without affecting current development work. With a few clicks, a user can now virtually guarantee that they are using the most recent Eclipse plugins and development environment available.

What About C?
One of the key points in the evolution of Eclipse that was of critical importance to embedded development was the development of the C/C++ Development Toolsuite or CDT. The CDT was originally designed and developed by QNX as a complete development environment for C and C++ developers utilizing the GNU development tools.

With the addition of the CDT, developers could now develop and debug not just standalone Java applications or Eclipse plugins in Java but actual local and embedded C and C++ code. As the GNU cross-compiler tools and binary utilities are very familiar to users of many IDEs and Real-Time Operating Systems, this made Eclipse a compelling solution for embedded development.

The C/C++ perspective provided by the CDT plugins updated both the Eclipse Project Managers and the Eclipse Debug Perspectives to accommodate local and remote debugging of code via GDB and the GDB Server in addition to the existing Java functionality. Now the Eclipse framework could be used with 3 languages.

It was therefore just a matter of time before additional interfaces for languages like COBOL, FORTRAN and Ada among others would also be provided by vendors. Now the embedded industry in particular is seeing many of the "old guard" companies who used to provide a completely proprietary IDE now providing Eclipse-based solutions of one sort or another. Many of these vendors are now bringing brand new approaches and brand new operating systems to the new Eclipse model.

Viewing the Eclipse
The Eclipse framework has gone through many changes in a very short amount of time. New plugins are being added all the time and the Eclipse framework has graduated to the status of an ecosystem where open source members, commercial vendors, and users all communicate to better the environment and to add an ever increasing level of functionality.

Figure 2: Callisto Update List

In an effort to increase the overall amount of capability provide by Eclipse, an ambitious new project is coming to fruition known as Callisto (Figure 2 above). Callisto is part of the Eclipse 3.2 release but it entails more than just a new release of the core Eclipse environment.

Callisto is also a synchronization point for several distinct Eclipse projects including the CDT, the Business Intelligence and Reporting Tool (BIRT), Graphical Editing Framework (GEF) and several others. A complete list can be found on the specific web pages.

In addition to Callisto, even newer capabilities are being added for Device Software Optimization (DSO), Remote Target Management and Rich Client Platforms (RCP) among a veritable host of others.

Not only is the Eclipse framework here to stay, but an ever widening circle of development problems are being addressed by it. It is fast becoming a defacto standard for development environments of many kinds across a multitude of industries including the embedded space.

Mike McCullough is Director, Professional Services at Embedded Planet, a provider of hardware and software to the embedded industry. He has published several articles on Eclipse plug-in development and Linux board support package development.

Other Eclipse resources on Embedded.com: