© Raldi Somers, 123RF.com

Die Entwicklungsumgebung Eclipse bietet dem C- und C++-Programmierer einen großen Reichtum an Funktionen. Wer damit aber auf Linux geeichte Anwendungen schreiben möchte, ohne hinter dem Rücken der IDE noch mit Autotools, GDB und Profiler zu hantieren, dem bietet die Plugin-Sammlung Linux Tools [1] ihre Dienste an.

Angeflanscht

Wie ihr Name schon andeutet, verbirgt sich dahinter ein Paket aus mehreren Plugins, die jeweils ein Entwicklerwerkzeug in Eclipse einbinden, eine komplette Aufstellung liefert der Kasten “Alle Plugins im Überblick”. Derart aufgerüstet generiert die IDE per Mausklick ein »configure«-Skript oder erstellt per Tastaturkommando einen kompletten Changelog-Eintrag.

Das Projekt Linux Tools befindet sich allerdings noch in der so genannten Incubation-Phase [2] der Eclipse Foundation und somit erst am Anfang der Entwicklung. Darauf verweist auch die niedrige Versionsnummer 0.5.1. Bis auf einige Ausnahmen sind die Plugins jedoch schon jetzt durchaus stabil, in der Praxis äußerst nützlich und schnell installiert – und das selbst unter der aktuellen Helios-Release von Eclipse. Entwickler von Linux-Programmen sollten sie daher unbedingt einmal probefahren. Bei der Installation der Tools hilft der Kasten “Einbauanleitung”.

> Autotools

Linux-Programme übersetzt in der Regel der berühmte Dreischritt »configure; make; make install«. Das Configure-Skript nebst passenden Vorlagen für die Makefiles generieren die Programme der GNU Autotools. Das gleichnamige Linux-Tools-Plugin integriert diese Werkzeuge in Eclipse. Dazu fügt es zunächst einen neuen Autotools-Projekttyp ein. Er basiert auf dem altbekannten Makefile-Projekt, folglich stehen alle dafür gedachten Eclipse-Funktionen und -Einstellungen auch für Autotools-Projekte parat.

Der Project Wizard (beispielsweise über »File | New | C++ Project« erreichbar) offeriert dabei sowohl ein komplett leeres Autotools-Projekt als auch ein kleines »Hello World«-Programm. Entscheidet man sich für letzteres, erstellt das Plugin automatisch alle von den Autotools geforderten Konfigurationsdateien. Es empfiehlt sich folglich, ein neues Softwareprojekt auf der Hello-World-Vorlage aufzubauen, während man das »Empty Project« vorzugsweise mit bereits vorhandenem Quellcode füttert. Templates für »configure.in«- und »Makefile.am«-Dateien wird es erst in einer künftigen Auflage der Linux Tools geben.

Alternativ darf der Anwender ein bestehendes Projekt in dessen Autotools-Pendant umwandeln. Danach gibt es allerdings kein Zurück mehr: Ein Autotools-Projekt lässt sich derzeit nicht ohne größeren Aufwand wieder in ein normales C/C++-Projekt überführen. Egal für welchen Weg sich der Eclipse-Benutzer entscheidet, ab sofort genügt ein Klick auf den Build-Knopf, um »autoconf«, »automake« & Co. in der richtigen Reihenfolge anzuwerfen. Danach startet das Linux-Tools-Plugin das dabei generierte Configure-Skript und übersetzt den Quellcode wie gewohnt per »make all«. Es merkt sich durchlaufene Schritte und führt sie nicht noch einmal aus.

Über »Project | Invoke Autotools« oder per rechtem Mausklick auf eine der für die Autotools bestimmten Dateien im »Project Explorer« aktiviert der Programmierer die Werkzeuge bei Bedarf auch einzeln. Selbstverständlich darf er in einem Autotools-Projekt eine eigene »Build Configuration« anlegen und dabei das »configure«-Skript mit speziellen Parametern füttern.

Hürdenlauf

Das alles klappt freilich nur, wenn auf dem Rechner die benötigten Autotools-Werkzeuge installiert sind. Viele Linux-Distributionen teilen Autoconf, Automake und die Libtools gerne in mehrere Pakete auf. Fehlt eines davon, bricht der Übersetzungsvorgang mit einer nichts sagenden Meldung in der Eclipse-Konsole ab. Darüber hinaus darf der Projektname keine Leerzeichen enthalten, andernfalls beschwert sich Make über unbekannte Targets. Apropos Targets: Auch die automatisch generierten erscheinen wie gewohnt in der »Make Target«-Ansicht, wo sie der Anwender einzeln per Mausklick anstoßen kann.

Die Automatiken hören jedoch genau da auf, wo das eigene Projekt komplexere Formen annimmt. Um beispielsweise Qt-, GTK+- oder SDL-Bibliotheken einzubinden, muss der Programmierer doch wieder selbst Hand an die Konfigurations- beziehungsweise Eingabedateien der Autotools legen.

Zum Ausgleich bringt das Plugin für diesen Zweck passende Editoren mit. Sie bieten das übliche Programm aus Syntax-Highlighting, Content-Assistenz über [Strg]+[Leertaste], passende Tooltipp-Hilfen und eine derzeit noch rudimentäre Anzeige von Tipp- und Syntaxfehlern (Abbildung 1). Zusätzlich zeigt die Outline-Ansicht die Struktur der Konfigurationsdateien an, darunter bei »configure.ac« die Makros und Kontrollanweisungen (wie »if«, »else«, »for«), im Fall eines »Makefile.in« beispielsweise die Variablen und Targets.

Abbildung 1: Beim Erstellen von »configure.ac«-Dateien liefert der neue Editor des Autotools-Plugins vielfältige Unterstützung. Zusätzlich listet die Outline-Ansicht rechts die verwendeten Makros auf.

> Libhover

Die in Eclipse beziehungsweise im verwendeten C/C++ Development Tooling (CDT, [3]) eingebaute Autovervollständigung und Content-Assistenz erleichtert die Arbeit des Entwicklers spürbar. Häufig wünscht sich der Programmierer aber noch ein paar ausführlichere Informationen. Hier springt das Libhover-Plugin ein: Sobald man den Mauszeiger über einer Bibliotheksfunktion schweben lässt, erscheint ein ausführlicher Tooltipp dazu (Abbildung 2).

Abbildung 2: Das Libhover-Plugin liefert in einem riesigen Tooltipp-Fenster ausführliche Informationen zu einer Bibliotheksfunktion, hier für »printf()«.

Das Plugin ist so konstruiert, dass sich jederzeit weitere Tooltipp-Inhalte zu anderen Bibliotheken nachrüsten lassen. Derzeit kann man im »Install«-Fenster über die »Linux Tools Additional Library API« Informationen zur »newlib« hinzufügen. Weitere Bibliotheken, insbesondere aus dem C++-Bereich, sollen folgen. Künftig möchten die Plugin-Macher die Inhalte automatisiert aus den Kommentaren des Quellcode beziehungsweise der vorhandenen Dokumentation der Bibliotheken generieren.

> Changelog

Das Changelog-Plugin entpuppt sich als kleiner, aber pfiffiger Helfer im Hintergrund. Per »Project | Prepare Changelog« sammelt es alle bislang ausgeführten Quelltext-Änderungen ein und erzeugt daraus einen neuen Changelog-Eintrag. Diesen kann der Entwickler im eigens dafür abstellten Editor nachbearbeiten und ergänzen. Er kennt wiederum Syntax-Highlighting und ruft bei einem Klick auf einen Dateinamen oder eine URL das passende Ziel auf. Eine einzelne, nachträgliche Änderung lässt sich über den Menüpunkt »Edit | Changelog« dem bestehenden Eintrag hinzufügen.

> Valgrind

Das Debugging erfolgt wie gewohnt durch CDT mit Hilfe von GDB. Speicherlecks spürt hingegen Valgrind [4] auf. Aus dieser vielfältigen Werkzeugsammlung unterstützt das zugehörige Linux-Tools-Plugin allerdings nur Memcheck, Massif und Cachegrind.

Um ein fertiges Programm von Valgrind inspizieren zu lassen, klickt der Anwender es einfach mit der rechten Maustaste im Project Explorer an und wählt »Profile As | Profile With Valgrind«. Dies entspricht einem Aufruf von »valgrind Programmname«. Wer mehr Einfluss ausüben möchte, legt eine neue »Profile Configuration« an (via »Run | Profile Configurations…«). Wie die bekannten »Build Configurations« fasst sie alle Parameter eines Valgrind-Durchlaufs unter einem Namen zusammen. In den Einstellungen einer »Profile Configuration« wechselt man auch zu anderen Valgrind-Werkzeugen (Register »Valgrind Options«).

Abbildung 3: Hier hat Valgrind gleich mehrere Speicherlecks aufgespürt. Selektiert man eines in der Liste, erscheint im Editor die betreffende Zeile hervorgehoben – wie hier für den nicht freigegebenen Speicher.

Die Ergebnisse eines Valgrind-Laufs schreibt das Plugin in eine eigene Ansicht (Abbildung 3). Nach einem Klick auf ein erkanntes Problem springt Eclipse umgehend zum potenziellen Verursacher im Quelltext. Sofern Massif zu Werke ging, erscheint ein Graph, der den Speicherverbrauch – genauer gesagt den genutzten Heap – über die Zeit anzeigt (Abbildung 4). Jeden Messpunkt (Snapshot) führt die Valgrind-Ansicht noch einmal in einer Liste auf, ein Doppelklick zeigt weitere Informationen über die Verursacher.

Abbildung 4: Hier zeigt Massif den Speicherverbrauch in den ersten Lebenssekunden des Amiga-Emulators UAE. Die einzelnen Messpunkte listet die Ansicht am unteren Rand noch einmal ausführlich auf.

> Callgraph-Plugin

Wem die »Debug«-Ansicht nicht mehr ausreicht oder zu spartanisch erscheint, der darf sich die Aufrufbeziehungen vom Callgraph-Plugin in einem hübschen Diagramm aufmalen lassen. Dazu stößt der Anwender wie bei Valgrind einfach die entsprechende »Profile Configuration« an (»Run | Profile As | Function callgraph«), wartet einen Moment und betrachtet dann das Ergebnis in der »Call Graph«-Ansicht. Jeder Knoten entspricht einem Funktionsaufruf, an den Kanten notiert das Plugin die Anzahl der Aufrufe, während die Prozentzahlen den Anteil an der Gesamtlaufzeit des Programms angeben (Abbildung 5). Nach einem [Strg]-Doppelklick auf eine Funktion öffnet sich diese umgehend im Editor.

Abbildung 5: Der rekursive Aufruf der »fakultaet()«-Funktion ist in Callgraph sehr gut als Kette zu erkennen.

Die kleinen Symbole dieser Ansicht schalten zwischen verschiedenen Darstellungen um. Der »Aggregat Mode« zeigt beispielsweise jede Funktion als Kästchen an. Je größer es ist, desto häufiger wurde die Funktion aufgerufen. Das Kontextmenü hinter dem kleinen weißen Dreieck hält weitere Funktionen bereit, unter anderem lässt sich der Graph als Datei im DOT-Format speichern. Als besonderen Augenschmaus animiert die View die Abläufe bei einem Klick auf den grünen Pfeil nach rechts.

Das Callgraph-Plugin greift im Hintergrund auf die Dienste des Systemtap-Werkzeugs zurück. Bevor das Tool zum ersten Mal ein Programm inspiziert, muss der Benutzer per Hand ein Kernelmodul übersetzen. Das Eclipse-Plugin weist darauf mit einer entsprechenden Meldung hin, der dort falsch angegebene Befehl lautet für die meisten aktuellen Distributionen allerdings korrekt:

sudo make -C /usr/share/systemtap/
runtime/uprobes

Unter Ubuntu 10.04 fehlt zudem offenbar eine wichtige Headerdatei [5], folglich lässt sich das Modul nicht übersetzen, Systemtap nicht aktivieren und somit wiederum kein hübscher Aufrufgraph produzieren. Apropos Systemtap: Für dessen Skripte halten die Tools ein eigenes Editor-Plugin bereit.

> Oprofile

Programmteile mit langen Laufzeiten sind heiße Kandidaten für Optimierungen. Wie viel Rechenleistung welche Funktionen fressen, ermittelt Oprofile. Dank passendem Linux-Tools-Plugin sollte dazu unter Eclipse ein Rechtsklick auf die ausführbare Datei und die Wahl von »Profile As | Profile With OProfile« genügen. Soweit zumindest das Demonstrationsvideo aus dem Linux-Tools-Wiki [6]. Die Praxis sieht anders aus: Beim ersten Start meldet sich das Plugin mit einer üppigen Fehlermeldung.

Sowohl unter Fedora 13, Open Suse 11.2 als auch Ubuntu 10.04 mussten die Tester zunächst ein Hilfsprogramm »opxml« erzeugen, was laut Anleitung eigentlich nur in Sonderfällen notwendig ist. Unter Ubuntu arbeitete das Plugin zudem erst, nachdem Oprofile aus den aktuellen Quellen neu übersetzt war. Dennoch wurden unter allen getesteten Distributionen laut Plugin keinerlei Profiling-Informationen generiert. Weitere Enttäuschungen über Plugins verzeichnet der Kasten “Irrungen und Wirrungen”.

> RPM-Specfile

Sobald das selbst geschriebene Programm sämtliche Tests bestanden hat, schnürt es der Entwickler zu einem Paket und liefert es aus. Die Linux Tools unterstützen diesen Schritt mit ihrem Specfile-Editor-Plugin. Es stellt im Wesentlichen einen Editor für ».spec«-Dateien bereit, die wiederum dem »rpm«-Programm mitteilen, welche Dateien es wie zu einem vollständigen RPM-Archiv verpacken soll. Das ».deb«-Format von Debian-basierten Distributionen bleibt gegenwärtig noch außen vor.

Um für das aktuelle Projekt ein neues Specfile zu erstellen, konsultiert der Anwender den Assistenten hinter »File | New | Other…«, wählt das »Specfile based on a template« (in der Gruppe »RPM«) und ergänzt das angezeigte Formular. Dieser kurze Dienstweg spuckt allerdings nur dann eine vorgefertigte ».spec«-Datei aus, wenn zuvor »rpmdev-newspec« installiert wurde. Fedora 13 versteckt dieses Werkzeug im Paket »rpmdevtools«, unter den meisten anderen Distributionen sucht man es hingegen vergebens. Somit bleibt in der Regel nichts anderes übrig, als die ».spec«-Datei doch wieder per Hand anzulegen.

In jedem Fall erscheint das Specfile in einem eigenen Editor, der neben dem obligatorischen Syntax-Highlighting auch eine Content-Assistenz bietet und das Ein- und Ausklappen von Blöcken beherrscht (Abbildung 6). Ein Klick auf einen Dateipfad öffnet die referenzierte Datei direkt in Eclipse, die Outline-Ansicht zeigt die Dateistruktur.

Abbildung 6: Der Specfile-Editor erlaubt ein bequemes Bearbeiten der gleichnamigen RPM-Konfigurationsdateien. Die »Outline«-Ansicht zeigt die einzelnen Abschnitte an.

Auf Wunsch fügt das Plugin dem Projekt einen neuen Builder hinzu (via rechte Maustaste im Project Explorer und dann »Add/Remove Rpmlint Warnings«). Dieser nimmt zusammen mit dem externen Werkzeug »rpmlint« bei jedem Übersetzungsvorgang die Specdatei unter die Lupe. Entdeckte Fehler oder Warnungen erscheinen übersichtlich in der »Problems«-Ansicht. Für häufig wiederkehrende beziehungsweise bekannte Fehler bietet das Kontextmenü einer solchen Meldung eine Quick-Fix-Funktion, die den Fehler selbstständig behebt. Wie gut das letztlich klappt, hängt von der Komplexität des Specfile ab.

> Lttng

Primär an Kernel- und Treiberentwickler richtet sich das Lttng-Plugin. Es installiert eine komplett neue Perspektive, die von dem Tool Lttng erzeugte Traces aufbereitet und somit den Viewer LTTV ersetzen möchte. Bevor der Benutzer auf die Lttng-Perspektive umschaltet, sollte er dringend via »Help | Check for Updates« die neueste Version des Plugins einspielen, sonst hagelt es Fehlermeldungen. Anschließend benötigt er noch die Lttng-Parsing-Library des LTTV, deren Quellcode er per Hand von der Lttng-Homepage herunterladen und übersetzen muss. Danach genügt es, ein neues »LTTng Project« anzulegen und einen vorhandenen Ordner mit den Traces zu importieren (Rechtsklick auf »Traces« im »Project Explorer«).

Anschließend erstellt der Linux-Entwickler ein neues »Experiment« und befüllt es mit den zu untersuchenden, soeben importierten Traces. Ein Doppelklick auf ein Experiment schiebt dann die Traces in die Ansichten. Die dort dargestellten Informationen und Statistiken entsprechen denen des LTTV-Hauptfensters.

Gemischtwarenladen

Den Einstieg in die Linux Tools erleichtern Videos, die das Wiki [6] im Ogg-Format anbietet. Ein weiterer Blick sollte in die Onlinehilfe gehen. Die Qualität der dortigen Dokumentation schwankt jedoch von Plugin zu Plugin, von erschöpfend bis nicht vorhanden. Den Linux Tools ist deutlich anzumerken, dass sie ursprünglich aus mehreren einzelnen Projekten zusammengepresst wurden. Fast alle Plugins könnten noch Feinschliff vertragen, einige sind unübersehbar auf Fedora ausgerichtet.

Das soll aber nicht darüber hinwegtäuschen, dass die meisten schon jetzt wertvolle Hilfen für den Programmierer-Alltag bieten, allen voran die Autotools-, Changelog- und Valgrind-Plugins. Wohin die Reise einmal gehen soll, verraten der Projektplan [7] und die Internetseiten der einzelnen Plugins. (mhu)