Staus quo plus Aussicht auf Version 4.0

Eclipse C/C++ Development Tools (CDT)

Doug Schaefer

Mit Eclipse gibt es eine Plattform, die Entwicklungswerkzeuge verschiedener Anbieter in einem gemeinsamen, erweiterbaren und breit unterstützten Framework vereint. Das Eclipse-Projekt C/C++ Development Tools, kurz CDT, erschließt die in Eclipse integrierten Tools für die C- und C++-Programmierung, sodass Entwickler ihre Produktivität und die Qualität ihrer Software verbessern können.

Das CDT-Projekt startete im Sommer 2002 mit Quellcode, der von QNX Software Systems programmiert und zur Verfügung gestellt wurde. Seitdem haben Entwickler zahlreicher weiterer Unternehmen und Organisationen ebenfalls zu CDT beigetragen, sodass es heute eine ausgereifte Entwicklungsumgebung von kommerzieller Qualität ist. CDT bringt deine Reihe erfahrener Köpfe der C/C++-IDE-Szene zusammen und deckt deshalb die unterschiedlichsten Anforderungen vieler Entwickler ab.

Mit CDT 3.1 veröffentlichte das Projektteam im Sommer 2006 Funktionalitäten, die sich im Vergleich mit anderen kommerziellen und Open-Source-Entwicklungsumgebungen messen lassen können. Bei der Entwicklung dieser Version legte das CDT-Team besonderen Wert auf die Skalierbarkeit großer Entwicklungsprojekte. Zudem entstand eine Basis, die CDT über den Edit-Compile-Debug-Zyklus hinauswachsen lässt.

Im Folgenden stellt der Artikel CDT selbst, aber auch die neuen Features der Version 4.0 vor und gibt einen Ausblick auf kommende Funktionalitäten, die CDT reaktionsschneller und skalierbarer machen sollen. Weitere Punkte dieses Artikels betreffen die wachsende Akzeptanz von CDT und die Möglichkeiten, sich als Entwickler an diesem Projekt beteiligen zu können.

Überblick CDT

CDT besteht aus drei Hauptkomponenten:

  • CDT Core: hilft Entwicklern beim Erstellen, Bearbeiten und Navigieren von Projekten
  • CDT Build: integriert Build-Tools, um innerhalb eines Projektes ausführbare Programme, so genannte Executables, zu erstellen
  • CDT Debug: integriert native Debugger für ausführbare Programme
CDT Core

Der CDT Core besteht aus verschiedenen Komponenten wie Projektassistenten, Quellcode-Editor und Quellcode-Navigatorsystem.

Abb. 1: Ansicht des C/C++-Projektassistenten

Projektassistenten: Die Projektassistenten helfen bei der Erstellung von CDT-Projekten. Es gibt je einen Assistenten für C und C++ sowie für jedes unterstützte Build-System. Mit den Assistenten können Entwickler schnell die Eigenschaften und Build-Einstellungen für ein Projekt festlegen und optionale CDT-Features aktivieren oder deaktivieren.

Quellcode-Editor: Der CDT-Quellcode-Editor bietet ein modernes Feature-Set, um C-/C++-Quellcode zu durchsuchen und zu bearbeiten. So kann der Editor beispielsweise

  • Schlüsselwörter und Literale im Quellcode farbig hervorheben,
  • die Positionen zusammengehörender eckiger und geschweifter Klammern anzeigen,
  • mit Features für die Code-Formatierung den Code nach links oder rechts verschieben und Codezeilen kommentieren,
  • Code vervollständigen, indem nach Eingabe des Anfangs eines Identifiers eine Liste möglicher Ergänzungen zur Auswahl erscheint.

Abb. 2: Anpassen der Anwenderpräferenzen für den C/C++-Quellcode-Editor

CDT bietet mit seinem eingebauten Parser eine genau zur Situation passende Liste an Code-Ergänzungen, da diese auf dem Kontext des vom Anwender geschriebenen Codes aufgebaut wird. So entfällt die Zeit für das Eintippen des ganzen Namens. Dank API-Unterstützung erübrigt sich außerdem zum Beispiel bei OS-Funktionsaufrufen auch der Griff zum gedruckten Handbuch.

Quellcode-Navigation: Verschiedene CDT-Features helfen Entwicklern dabei, sich im Code eines Projektes zurechtzufinden. Sie sind vor allem dann nützlich, wenn ein Entwickler sich neu in ein existierendes Projekt einarbeitet und nicht zwangsläufig weiß, wo bestimmte Teile des Codes definiert sind oder wo dieser referenziert wird. Im Mittelpunkt des CDT-Quellcode-Navigators steht das Document Object Model, kurz DOM. Es bietet eine Datenbank mit Syntax- und Semantikinformationen, die der im CDT eingebaute Parser für C und C++ sammelt. Diese Datenbank bleibt auch zwischen den Sessions in einem Index bestehen, den das CDT beim Speichern der Dateien im Dateisystem erstellt.

Abb. 3: CDT-Quellnavigation jetzt mit neuem Open-Definition-Feature, das Entwickler direkt zur Definition einer Klasse oder eines Typs bringt

DOM unterstützt unter anderem folgende Quellcode-Navigationsfunktionen:

C-/C++-Projektansicht: hilft dem Entwickler mit einer auf C/C++-Projekte fokussierten Ansicht beim Navigieren mit Quellcode, Elementen und Libraries.

  • Outline-Ansicht: zeigt Deklarationen in Quelldateien. Klickt der Entwickler auf eine Deklaration, springt der Quellcode-Editor direkt zur entsprechenden Zeile.
  • Suchfunktionen: Mit ihnen kann nach Deklarationen, Definitionen und Referenzen zu den Identifiern gesucht werden, die im Quellcode definiert oder über Dialoge eingegeben wurden. Der Entwickler kann die Suchergebnisse wie in einem Browser durchgehen. Klickt er auf ein Ergebnis, springt der Quellcode-Editor zum entsprechenden Punkt in der Quelldatei.
  • Quellcode-Refactoring: Mit diesem Feature können Entwickler die Code-Struktur ändern, ohne das Code-Verhalten zu beeinflussen. Die häufigste Verwendung ist das Umbenennen eines Identifiers, die sich durch diverse Quellcodes zieht. Mithilfe des DOM erfolgt das Refactoring auf intelligente Weise, sodass Änderungen keine Kompilierungsfehler nach sich ziehen.

Fast Indexer: Mit Version 3.1 wurde der CDT Source Indexer, der viele der Quellcode-Navigationsfunktionen mit Informationen versorgt, weitgehend umstrukturiert. Der neue FastIndexer nutzt den internen CDT Parser, um die Index-Datenbank zu befüllen. Statt kompletter Parsings wie beim FullIndexer verwendet der Fast Indexer verschiedene Shortcuts, sodass das Erzeugen der Index-Informationen schneller geht. Da der neue Indexer Parse-Informationen von Datei zu Datei wieder verwendet, erübrigt sich der Aufwand für das ständige Parsen der Header-Dateien, wenn diese von anderen Dateien inkludiert werden. Mit dieser Heuristik kann der Fast Indexer den gesamten Quellcode von Mozilla in einem Viertel der Zeit parsen, die der Full Indexer dafür benötigt.

Auch durch Dateiänderungen ausgelöste Index-Aktualisierungen profitieren von den wiederverwendeten Informationen. Ein Update dauert so in der Regel weniger als eine Sekunde. Unter dem Strich verkürzen diese Verbesserungen die Antwortzeiten des User Interface.

CDT Build

Build-Tools für C/C++ gibt es seit langem. Projektteams haben viel Zeit in ihre meist sehr komplexen Build-Umgebungen investiert. Um dies zu berücksichtigen, wurden die CDT-Standard-Build-Projekte so entwickelt, dass bereits existierende Build-Umgebungen auch weiterhin verwendbar sind. Andererseits sparen sich Entwickler bei neuen Projekten gerne die Zeit und Mühe für das Schreiben von Build-Dateien. Auch dies wurde berücksichtigt: Mit CDT lassen sich Build-Dateien gemäß der Projekteinstellungen generieren, ebenso wie eine Liste der zum Projekt gehörenden Dateien.

Abb. 4: Der neue C/C++-Build-Projektpräferenzdialog

Mit dem Managed-Build-System können Anbieter Beschreibungen ihrer Tool-Chains liefern, einschließlich Optionseinstellungen und Dateierweiterungen, die die Tools als Input nutzen und als Output generieren. CDT passt mit diesen Informationen die Property-Dialoge an, sodass Optionen pro Projekt oder pro Datei gesetzt werden können. Zudem generiert es mit diesen Informationen und den Benutzereinstellungen die beim Build verwendeten Build-Dateien, zumeist Makefiles. CDT integriert sich ohne weiteres Zutun in die gcc-Tool-Chain für die Entwicklung auf dem Host.

Zur DOM-Unterstützung benötigt CDT Build-Informationen, um die Quelldateien in einem Projekt sauber zu parsen. Die primär benötigten Informationen bestehen aus den Include-Pfaden der Header-Datei und den vom Preprozessor genutzten Makroeinstellungen der Kommandozeile. Für Managed-Build-Projekte trägt CDT diese Information aus den Benutzereinstellungen der Tool-Optionen zusammen. Ebenso ermittelt und liefert das Managed-Build-System die installierten Einstellungen für den beim Build verwendeten Compiler.

Für Standard-Build-Projekte ist die Ermittlung von Build-Informationen schwieriger, da CDT in diesem Fall die Build-Einstellungen für das Projekt nicht selbst verwaltet. Daher können Entwickler die Include-Pfade und Makros über den Property-Dialog des Projektes manuell eingeben.

CDT enthält einen Mechanismus, der diese Einstellungen automatisch findet. Der Mechanismus scannt den Build-Output, versucht, die verwendeten Build-Befehle zu erkennen und extrahiert von dort die Informationen. Dieser Vorgang funktioniert auch bei bereits gelaufenen Builds.

Für den Support verschiedener Tool-Chains erlauben das Standard- und das Managed-Build-System das Einstellen der Umgebungsvariablen, die vor dem Build in die Umgebung exportiert werden. Somit können Entwickler den Pfad zum Finden von Compilern und Linkern ändern und andere, für das Build-Tool benötigte Umgebungsvariablen festlegen.

CDT Debug

Die CDT-Debug-Komponente visualisiert die Debug-Session. Ein nativer Debugger wie gdb kümmert sich um die Haken und Ösen beim Ausführen der Applikation. Er setzt beispielsweise Breakpoints und extrahiert Variablenwerte. CDT unterstützt die Integration mit gdb unmittelbar über das textbasierte MI-Protokoll. Andere Debugger sind aufgrund der Erweiterbarkeit von CDT auf dieselbe Weise integrierbar.

Abb. 5: Umgebungsvariablen lassen sich pro Projekt und pro Konfiguration setzen

CDT bietet die bei Eclipse üblichen Visualisierungen für das Debuggen, einschließlich Thread-Liste, Stack Frames für aktuell angehaltene Threads und Variablenwerte. Mit CDT 3.1 wurde eine neue Memory-Ansicht eingeführt, welche mehrere Formate für Speicherinhalte unterstützt und mit der Entwickler mehrere Stellen gleichzeitig durchsuchen können. Die Modul-Ansicht zeigt während des Debuggens das ausführbare Programm sowie die Shared Libraries und Objekte, die es geladen hat. Sie kann jede verfügbare Symbolinformation darstellen, sodass Entwickler bei in den Modulen definierten Funktionen Breakpoints setzen können. CDT bietet auch eine Register-Ansicht für das C/C++ Debugging. Die Register sind gruppierbar, was bei Prozessoren mit zahlreichen Registern besonders nützlich ist.

Abb. 6: Der neue Debugger mit Modul-Ansicht

Abb. 7: Der neue Debugger mit Register-Ansicht
Zukunftsaussichten

CDT 4.0 ist für Sommer 2007 geplant. Aufgrund der vielen Beiträge wird das neue CDT-Release eine Reihe spannender Features bereitstellen, die das User-Erlebnis verbessern, die Produktivität erweitern und eine noch größere Skalierbarkeit bieten. Derzeit sind unter anderem folgende Features in der Entwicklung:

  • Internal Builder: verbessert die Build Performance, da die Verarbeitung von Makefiles wegfällt. Der Internal Builder bestimmt, welche Dateien in einem Build auszuführen sind. Er nutzt die Fähigkeit von Eclipse für das Tracken von Dateiänderungen und von Informationen über Abhängigkeiten zwischen Dateien, die im CDT-Quellindex gespeichert sind. Der Builder kompiliert auch parallel und verkürzt so die Build-Zeiten auf Multicore-Plattformen.
  • Support für vorgefertigte Index-Informationen: Mithilfe des CDT Indexer können Anbieter von Software Development Kits (SDKs), wie etwa Betriebssystemhersteller, die Indexinformationen für die Header-Dateien im SDK vorfertigen und so die Index-Performance erhöhen. Der Indexer kann diese Information anschließend in den Index des Codes des Anwenders einfügen und vermeidet das Parsen der SDK-Header-Dateien in seiner Umgebung.
  • rweiterte Index-Informationen: Das CDT-Team hat die zu erfassenden Indexinformationen erweitert, um neue Ansichten für Navigation und Quellcode-Analyse zu ermöglichen. In der Call-Hierarchie-Ansicht können Anwender zwischen Funktionen und deren Unter- oder Aufrufer-Funktionen navigieren. In der Include-Hierarchie-Ansicht können sie zwischen Dateien navigieren, die in Inclusion-Beziehung stehen. Die Typ-Hierarchie-Ansicht schließlich erlaubt die Navigation zwischen C++-Klassen mit Erbbeziehungen.
  • Unterstützung für Windows SDK: Seit kurzem bietet Microsoft seine Compiler als kostenlosen Download zusammen mit seinem Windows SDK. CDT 4.0 wird dafür Build- und Debug-Unterstützung liefern, sodass unter Windows nicht mehr mit GNU-Tools entwickelt werden muss. Dies war problematisch, da die Tools eine Emulationsumgebung wie cygwin benötigen oder wie beispielsweise mingw das SDK nicht komplett unterstützen. Künftig werden auch Visual-Studio-Projekte auf CDT migrierbar sein.
  • Framework für die Projektgenerierung: Viele IDEs, die auf spezielle Plattformen zielen, können skelettartige Projekte für verschiedene Projekttypen generieren. Zum Beispiel kann in einem Projekt für eine Desktop-GUI-Applikation ausreichend Quellcode generiert werden, um ein Framework zum Laufen zu bringen und ein Fenster auf dem Bildschirm darzustellen. Dieser Code gibt dem Entwickler einen Vorsprung beim Aufbau von Projekten. CDT 4.0 wird das Framework für einen derartigen Projektaufbau liefern.
Teil der CDT Community werden

CDT hat eine große und vielfältige Community, deren Mitglieder auf verschiedene Weise zur Gemeinschaft beitragen. Mitarbeiter etwa von IBM, Intel, QNX Software Systems, Texas Instruments und Wind River sind zu Code-Änderungen berechtigt. Andere Mitglieder wie HP, Siemens und Symbian tragen in einem kleineren, aber dennoch wichtigen Rahmen mit Patches zum Erfolg von CDT bei. Weitere Mitglieder beteiligen sich, indem sie testen, Fehlermeldungen weiterleiten und Erweiterungen anregen.

Im Oktober 2006 veranstaltete QNX Software Systems einen weiteren erfolgreichen CDT Contributors Summit in Ottawa, Kanada. Die teilnehmenden Mitglieder von über 20 großen Organisationen repräsentierten die Bereiche Embedded, Enterprise sowie Forschung und Wissenschaft im C/C++-Markt.

CDT wird an vielen Orten und von vielen Menschen genutzt. Die Anzahl der CDT-Downloads steigt stetig und liegt derzeit bei 80.000 pro Monat. Diese Zahlen stehen für den großen Teil der allgemeinen Eclipse-Community und verdeutlichen, dass CDT nach der Eclipse-Plattform eines der beliebtesten Eclipse-Projekte ist. Das zeigt deutlich, dass der Eclipse-Wirkungskreis inzwischen über die Java-Entwicklung weit hinausgeht.

Die CDT-Community ist immer offen für neue Beiträge. Aktuelle Informationen und Richtlinien stehen auf wiki.eclipse.org unter „CDT Project“ zur Verfügung. Über cdt-dev at eclipse.org diskutiert die Community technische Fragen und trifft Programmentscheidungen.

Doug Schaefer ist Projektleiter des Eclipse CDT Project und als Senior Software Engineer bei QNX Software Systems tätig.
Geschrieben von
Doug Schaefer
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.