Channels ▼
RSS

Embedded Systems

Extending the Eclipse CDT Managed Build System


Eclipse and Builders

The CDT and the Java Development Tools (JDT) environment share many similarities, but they also differ in several ways. One of these differences is in how they build user projects.

Eclipse defines the concept of a project, which is an Eclipse resource. A project contains other Eclipse resources, specifically folders and files. A CDT project is a specialized Eclipse project that requires additional information to treat project resources as the source files of an application or library written in C/C++. One example is the set of include directories to be used when compiling the source files.

Eclipse also defines the concept of a builder and lets projects define which builder(s) they will use. CDT builders differ from JDT builders in two important ways:

  • CDT can support many different C/C++ compilers, whereas JDT supports a single Java compiler. To provide this support, MBS requires a tool-chain, a set of tools (minimally, a compiler and linker) used for building a project.
  • MBS requires the concept of a build configuration. C/C++ projects use the C preprocessor and compiler options to define different ways to build a project (typically debug and release configurations, at a minimum). Java doesn't have a preprocessor or any conditional compilation capability, and compiler options are very limited. Each CDT build configuration uses a particular tool-chain to build a project. Different build configurations in a project can use different tool-chains.

To add functionality to Eclipse, you provide packages of Java code called plug-ins. Plug-ins "plug into" extension points defined by lower levels of the Eclipse architecture. A plug-in can define additional extension points, allowing hierarchical layers of functionality to be constructed. Most Eclipse functionality, including JDT and CDT, is provided in the form of plug-ins. For more information, see Contributing to Eclipse by Erich Gamma and Kent Beck.

A builder is embodied by the Eclipse builder extension point, org.eclipse.core.resources.builder. MBS plugs into this extension point in order to be invoked by Eclipse whenever a build of an MBS project is required. To implement an Eclipse extension point, you fill out a well-defined XML schema that is specific to the extension point (see Listing One for the MBS extension to the Eclipse builder extension point). Implementing an extension point also often involves implementing a particular Java interface or subclassing a public Java class. For instance, to implement an Eclipse builder extension point, you must define a subclass of the org.eclipse.core.resources.IncrementalProjectBuilder class.


<!-- ========================================================== -- >
<!-- Extension Point: Makefile Generation Builder               -- >
<!-- ========================================================== -- >
  <extension
        id="genmakebuilder"
        name="%GeneratedMakefileCBuilder.name"
        point="org.eclipse.core.resources.builders">
        <builder
           hasNature="true">
          <run
            class=
"org.eclipse.cdt.managedbuilder.internal.core.GeneratedMakefileBuilder"& gt;
          </run>
     </builder>
  </extension>

Listing One: Extending the Builder Extension Point

CDT provides two distinct builders: the Managed Make builder provided by MBS and the Standard Make builder. A CDT user begins the development process by creating a CDT project. At the onset of project creation, the user must decide whether to create a Standard Make project or a Managed Make project. Although both project types use GNU make to build the project, they are different. With Standard Make, the CDT user must provide makefiles to build the project; with Managed Make, MBS automatically generates the makefiles required.

To generate the makefiles for a project, MBS uses information from three sources:

  • Eclipse project. The Eclipse project provides information about the resources contained within the project.
  • Tool-chain definition. A tool-chain integrator (possibly you) provides a description of the tools used to build the project.
  • User-specified options. The CDT user selects values for the tool options specified in the tool-chain definition.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video