next up previous contents index
Next: Bibliography Up: C++-Entwicklung mit Linux Previous: Werkzeuge für die Softwareentwicklung   Contents   Index

Subsections

Integrierte Entwicklungsumgebungen

Bisher haben Sie neben der Sprache C++ auch eine Reihe von Werkzeugen kennen gelernt, mit denen Sie eigentlich alle Entwicklungsaufgaben erledigen könnten. Das ist jedoch zuweilen etwas mühsam; während Freaks auf ihre Kommandozeilentools schwören, mutet Ihnen die Arbeitsweise vielleicht ein wenig archaisch an. Wesentlich bequemer und damit auch produktiver wird die Programmierung mit integrierten Entwicklungsumgebungen, integrated development environments oder kurz IDEs. Wenn Sie schon Programme unter Windows oder auf dem Mac geschrieben haben, kennen Sie sicher Umgebungen wie Microsoft Visual Studio, Borland Delphi oder Metrowerks CodeWarrior.

Diese verfügen alle über folgende Merkmale:

  1. Ein Editor steht zur Verfügung, der den Programmierer durch Syntaxeinfärbung, automatisches Einrücken und Querverbindung mit der Dokumentation unterstützt.
  2. Der Compiler kann direkt aus der IDE gestartet werden.
  3. Die Compileroptionen werden über Menüs beziehungsweise Dialoge eingestellt.
  4. Codestellen, an denen der Compiler Fehler findet, werden automatisch angezeigt.
  5. Die erzeugten Programme können sofort gestartet werden. Bei der Fehlersuche mit dem Debugger werden die gerade durchlaufenen Quelltexte im Editor angezeigt; Haltepunkte und Einzelschritte können dort aktiviert werden.
  6. Die Dateien, die zu einem Projekt gehören, werden über einen Dialog festgelegt. Makefiles werden automatisch erzeugt beziehungsweise sind überflüssig.
  7. Die Versionsverwaltung ist in die IDE eingebunden, so dass die Dateien über den Editor aus- und eingecheckt werden können.
Ich will Ihnen in diesem Kapitel vor allem eine IDE vorstellen, die alle diese Kriterien erfüllt (und noch einige mehr): SNiFF+ von WindRiver Software (ehemals TakeFive). In der Version für Linux und C++ ist sie kostenfrei erhältlich, so dass Sie sie auch auf beiliegender CD-ROM finden und gleich installieren können. Ab Seite [*] werden wir uns ausführlich damit beschäftigen.

Doch zunächst will ich Ihnen zeigen, dass auch der bereits vorgestellte XEmacs zu einer fast vollwertigen IDE werden kann. Abschließend werde ich Sie ab Seite [*] noch auf einige weitere interessante IDEs hinweisen.

XEmacs als IDE

Bereits als wir ab Seite [*] den XEmacs näher betrachteten, habe ich Sie darauf hingewiesen, dass er eigentlich viel mehr als nur ein Editor ist. Es gibt für ihn so viele Erweiterungen, dass Sie nichts anderes mehr benötigen. Natürlich gilt das auch im Hinblick auf die Programmierung. Wir wollen uns nun die wichtigsten Funktionen ansehen, die Sie bei der Verwendung des XEmacs als IDE brauchen werden.

Obwohl ich hier nur vom XEmacs rede, funktionieren die meisten der vorgestellten Merkmale auch beim GNU Emacs.

Der Editor

Dass der Editor Syntaxeinfärbung, Markierung von Klammern und automatisches Einrücken beherrscht, habe ich Ihnen schon auf Seite [*] gezeigt. Anhand der Dateiendung (.cc, .C, .cpp, .cxx, .hh oder .hxx) erkennt er automatisch, dass es sich dabei um einen C++-Quelltext handelt und passt seinen Modus entsprechend an. Auch die Navigationsmöglichkeiten ergeben sich daraus.

Liegt die Dokumentation zu einer Funktion im UNIX man-Format vor, so können Sie diese direkt im XEmacs aufrufen. Das ist zum Beispiel für die C-Standardbibliothek und einige sonstige Bibliotheken der Fall.

Angenommen, Sie möchten die Bedeutung der Parameter der Funktion strstr() wissen. Klicken Sie doppelt darauf, so dass sie markiert ist. Dann wählen Sie aus dem Menü HELP | MANUALS | UNIX MANUAL und erhalten in der Echo-Zeile, also der untersten Zeile des Fensters, die Meldung:

Manual entry (default strstr): 

Hier müssen Sie nur noch die Eingabetaste drücken und schon haben Sie die gewünschte Information vor sich.

Start des Compilers

Wenn Sie mit dem XEmacs Programme entwickeln, ist es am sinnvollsten, mit Makefiles zu arbeiten. Natürlich können Sie auch hier die Quelldateien einzeln übersetzen und linken lassen, aber das ist genauso mühselig wie über die Kommandozeile. Gehen wir also davon aus, Sie hätten bereits ein Makefile (diese lassen sich ja auch sehr komfortabel mit XEmacs erstellen und bearbeiten).

Um den Compiler zu starten, gibt es wieder viele Wege: Die Schaltfläche COMPILE, der Menüpunkt TOOLS | COMPILE oder ganz klassisch über die Tastatur: Alt+X und dann compile eingeben. Dann werden Sie noch gefragt, wie Sie make aufrufen wollen. Die Vorgabe enthält die Option -k, die dafür sorgt, dass der Übersetzungsvorgang nicht bei einer fehlerhaften Datei abgebrochen wird, sondern dass andere, die von dieser unabhängig sind, auch noch kompiliert werden.

Treten bei der Übersetzung Fehler auf, so werden die entsprechenden Meldungen im unteren Teil des Fensters angezeigt. Mit einem Klick darauf gelangen Sie sofort an die angegebene Stelle im Quelltext und können nach der Ursache suchen. Im Programm in Abbildung [*] fehlt einfach das Semikolon nach der Anweisung innerhalb der Schleife.

Figure: Meldet der Compiler Fehler, springt der XEmacs bei einem Klick in den Quelltext.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/xem-prgerrors.eps}}

Start des Programms und des Debuggers

Ebenso leicht ist es, das erfolgreich erzeugte Programm aus dem XEmacs zu starten. Da es ja auch einem Shell-Kommando entspricht, müssen Sie nur noch darauf achten, den richtigen Pfad zu verwenden. Als lokales Verzeichnis sieht der XEmacs immer das Verzeichnis an, aus dem er gestartet wurde. Liegt Ihr Programm nicht dort, müssen Sie einen relativen oder absoluten Pfad mit angeben. Rufen Sie also TOOLS | SHELL COMMAND oder Alt+! auf und geben Sie den Namen Ihres Programms und gegebenenfalls weitere Argumente ein. Wie Sie wissen, müssen Sie das nur das erste Mal tun; der XEmacs merkt sich solche Eingaben und lässt Sie mittels der Tasten $\uparrow$ und $\downarrow$ auf frühere zugreifen. Die Ausgaben Ihres Programms erscheinen dann in einem Fenster des XEmacs.

Wenn Sie Ihr Programm debuggen wollen, gehen Sie ähnlich vor. Standardmäßig ist der XEmacs mit dem gdb integriert, also dem textorientierten Debugger, den Sie von Seite [*] kennen. Wenn Sie nun TOOLS | DEBUG (GDB) wählen, werden Sie noch nach dem Namen der ausführbaren Datei gefragt und los geht's. Nun ändert sich auch die Leiste der Schaltflächen und es erscheinen solche, die für das Debuggen gebraucht werden (Abbildung [*]); wenn Sie den Mauszeiger über eine davon bewegen, können Sie deren Bedeutung in der Echo-Zeile lesen.

Figure: Beim Start des gdb aus dem XEmacs passen sich auch die Schaltflächen an.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/xem-gdb.eps}}



Nun können Sie entweder über die Schaltlfächen oder direkt an der Eingabeaufforderung des gdb alle bekannten Befehle aufrufen und auf diese Weise Schritt für Schritt die Fehler in Ihrem Programm suchen.

Versionsverwaltung mit XEmacs

Auch die Funktionen zur Versionskontrolle sind direkt in den XEmacs integriert. Unter Linux wird dabei standardmäßig RCS verwendet (siehe Seite [*]). Aber auch CVS und andere werden unterstützt. Die entsprechenden Funktionen sind hinter dem Menüpunt TOOLS | VC verborgen -- aber natürlich gibt es für alles auch wieder Tastenkürzel.

Die wichtigsten Funktionen sind:

Interessant ist es auch, die aktuell bearbeitete Version einer Datei mit der archivierten zu vergleichen. Dazu bietet sich Ediff an, zu dem wir gleich kommen.

Dateivergleich mit Ediff

Ein sehr hilfreiches Werkzeug zum Vergleich von Dateien, Verzeichnissen und anderem ist Ediff. Sie erreichen es über das Menü TOOLS | COMPARE des XEmacs. Wenn Sie das Untermenü öffnen, sehen Sie bereits die Möglichkeiten, die Ihnen Ediff bietet. Wir wollen hier zwei Dateien miteinander vergleichen, genauer zwei Versionen einer Datei.

Dazu rufen Sie TOOLS | COMPARE | FILE WITH REVISION auf. Um die Fragen, die XEmacs stellt, müssen Sie sich nicht weiter kümmern; Sie möchten ja ohnehin nur den Vorgabefall bearbeiten, nämlich den aktuellen Puffer mit seiner letzten archivierten Version vergleichen.

Anschließend öffnet sich ein kleines zusätzliches Steuerfenster, über das Sie Ihre Ediff-Befehle geben können. Dabei müssen Sie beachten, dass die Ediff-Tastenkombinationen nur dann funktionieren, wenn das Steuerfenster das aktive ist. Gerade wenn Sie Ihre Oberfläche so eingestellt haben, dass die Aktivierung der Fenster schon bei der Positionierung des Mauszeigers darüber erfolgen soll, kann es immer wieder zu Problemen kommen, die Ediff mit einem Piepser quittiert.

Das Arbeitsfenster des XEmacs teilt sich nun in zwei Bereiche auf, die die beiden miteinander zu vergleichenden Dateien (hier Versionen) enthalten (Abbildung [*]). Aus der jeweiligen Statuszeile erfahren Sie, welche welche ist.

Mit Hilfe von Ediff navigieren Sie nun durch die sich unterscheidenden Bereiche der Dateien. Diese sind jeweils andersfarbig hervorgehoben. Abweichende Zeilen werden als Ganzes markiert; einzelne Abweichungen darin werden mit einer weiteren Farbe hervorgehoben. In Prosa klingt das alles sehr kompliziert, wird aber beim konkreten Einsatz schnell einsichtig.

Figure: Die Unterschiede zwischen den Dateien werden durch verschiedene Farben hervorgehoben.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/xem-ediff.eps}}



Auch während des Vergleiches können Sie beide Fenster noch editieren (sofern nicht eines davon schreibgeschützt ist). Die meisten Aktionen geben Sie aber durch einfache Tasten über das Ediff-Fenster an. Die wichtigsten davon sind:

Zusammenfassung

Sie haben gesehen, dass der XEmacs sich durchaus gut für die Programmierung eignet. Viele der bekannten Open-Source-Programmpakete wurden mit ihm geschrieben. Er enthält einen komfortablen Editor mit Syntaxeinfärbung und Einrückung, erlaubt das Starten des Compilers und das Springen zu Fehlerstellen, integriert den Debugger und die Versionsverwaltung und bietet mit Ediff ein äußerst praktisches Werkzeug zum Vergleich von Dateien und Versionen.

Von den Kriterien für IDEs, die wir am Anfang des Kapitels aufgestellt haben, erfüllt er die Punkte 3 und 6 nicht. Gerade die Verwaltung größerer Projekte mit mehreren Abhängigkeiten wird so schwierig. Für Umsteiger aus der Windows-Welt sind vielleicht gerade diese Aspekte entscheidend, da sie den Umgang mit Make-Dateien nicht gewohnt sind. Aber auch diese Funktionen wird der XEmacs früher oder später beherrschen.


Source Code Engineering mit SNiFF+

Damit ein Programmierer produktiv arbeiten kann und nicht nur ständig von einem zum anderen Werkzeug wechseln muss, wünscht er sich eine Umgebung, die alle Werkzeuge integriert. Die kommerziell erhältlichen IDEs, die im Laufe der Jahre zu diesem Zweck auf den Markt gekommen sind, haben alle mehr oder weniger viele Nachteile. Die Anwender haben zwar gelernt damit zu leben, die höchste Produktivität konnten Sie damit aber nicht immer erreichen.

Das erste Problem war, dass die meisten IDEs nur für Einzelprogrammierer konzipiert sind. Auch die IDE-ähnlichen Erweiterungen des XEmacs, die wir gerade betrachtet haben, sind nur auf einen einzelnen Entwickler zugeschnitten; diese und andere Umgebungen bieten kaum Unterstützung für die enge Zusammenarbeit im Team.

Außerdem gibt es viele IDEs nur auf einer Plattform. Die meisten sind natürlich für Microsoft Windows verfügbar, einige auch für Macintosh, und jeder Hersteller eines kommerziellen Unix bietet auch eine IDE auf seinem Betriebssystem an. Für die Entwicklung von Programmen, die portabel, das heißt auf verschiedenen Plattformen lauffähig sein sollen, ist diese Einschränkung besonders hinderlich. Auf jedem System müssen dabei die Projektdefinitionen und Abhängigkeiten neu eingegeben werden.

Ein weiterer Schwachpunkt vieler IDEs ist es, dass sie mit großen Projekten (über 200.000 Zeilen Quelltext in mehr als 200 Dateien) nicht umgehen können. Bei den jeweils mitgelieferten Beispielen arbeiten sie noch sehr gut -- aber diese umfassen nur eine Handvoll Dateien. Sobald das Projekt wächst, treten häufig Defizite an Performance und Handhabbarkeit zu Tage.

Da die IDEs meist vom Hersteller eines Compilers entwickelt werden, ist es nicht verwunderlich, dass sie auch an diesen Compiler gebunden sind. Eine offene Architektur, die die Einbindung eines beliebigen Compilers und anderer Werkzeuge (Debugger, Make, Revisionsverwaltung) erlaubt, gibt es nur höchst selten. Gerade unter Linux mit seinen vielen effizienten und freien Werkzeugen ist diese Anforderung aber besonders wichtig.

Eine integrierte Entwicklungsumgebung, die alle diese Nachteile nicht hat, ist SNiFF+ von Windriver (vormals von TakeFive). Sie hat eine gute Teamunterstützung, ist für vielerlei Plattformen und eine Reihe von Programmiersprachen (C/C++, Java, Fortran, Cobol, Python, Perl etc.) verfügbar und kann auch wirklich große Projekte effizient verwalten. Der einzige Nachteil war lange Zeit der relativ hohe Preis. Doch auch da haben wir Glück: Die Penguin-Edition, die die C++-Entwicklung unter Linux unterstützt, ist kostenfrei erhältlich. Wenn diese nicht schon zusammen mit Ihrer Distribution geliefert wurde und Sie sie daher bereits installiert haben, finden Sie alles Nötige auf beiliegender CD-ROM (oder natürlich im Internet unter www.windriver.com).

Überblick über die SNiFF-Umgebung

Der etwas merkwürdige Name dieser Software kommt vom englischen Wort sniff, also schnüffeln. Als eine ihrer Hauptaufgaben versteht sie nämlich das selbstständige Analysieren von Quellcode. Dazu beinhaltet SNiFF+ eine Reihe von Werkzeugen:

Daneben liefert SNiFF+ einen leistungsfähigen Editor, eine Integration von Debugger und Revisionskontrolle und natürlich das erwähnte Projektmanagement. Das Besondere an SNiFF+ ist, dass es die für die Programmentwicklung grundlegenden Werkzeuge wie Compiler oder Debugger nicht selbst enthält, sondern lediglich die vorhandenen aufruft. Unter Linux ist das als Compiler standardmäßig der GCC, aber auch andere Compiler (mit ähnlichen Optionen) lassen sich benutzen. Überhaupt ist SNiFF+ im Hinblick auf die Integration von anderen Werkzeugen ungeheuer vielseitig. Fast jedes Werkzeug lässt sich in die IDE integrieren. Sie können eigene Menüpunkte hinzufügen und komplette Abläufe umstellen. Die Programmierschnittstelle in Python macht SNiFF+ besonders offen; diese Schnittstelle wird auch intern benutzt, wobei die entsprechenden Skripte im Quelltext mitgeliefert werden und daher ebenfalls adaptiert werden können -- falls Sie das wollen.

Projekte in SNiFF+

Projekte sind in SNiFF+ hierarchisch organisiert. Das bedeutet, dass jedes Projekt ein oder mehrere Unterprojekte haben kann, von denen es abhängt. Auch diese können wieder eigene Unterprojekte haben und so weiter. Dabei können Sie frei einstellen, welches Ergebnis ein Unterprojekt nach oben liefern soll: seine Objektdateien, eine Bibliothek oder eine eigene ausführbare Datei. SNiFF+ legt fest, dass ein Projekt denselben Namen tragen muss wie das Verzeichnis, in dem es sich befindet. Das ist im Allgemeinen keine Einschränkung, sondern fördert die Einfachheit und Übersichtlichkeit eines Projekts. Zusätzlich müssen alle verschiedenen Projekte in einer Hierarchie auch verschiedene Namen tragen (obwohl sie für Filesystem und Compiler eigentlich durch ihren Pfad eindeutig bestimmt sind). Findet SNiFF+ beim Analysieren eines bestehenden Projekts ein solches Unterverzeichnis zum wiederholten Mal, so wird der Projektname aus dem Verzeichnisnamen des darüber liegenden Ordners und des aktuellen zusammengesetzt. In net/src und img/src werden beispielsweise net_src.proj und img_src.proj angelegt.


Der Projekteditor

Als Beispiel betrachte ich in diesem Abschnitt vorwiegend die freie Bibliothek Qt, da unsere bisherigen Beispiele doch recht klein waren und daher nicht die Funktionalität von SNiFF+ so gut veranschaulichen konnten. Qt ist eine vorbildlich aufgebaute C++-Bibliothek, die vor allem als Basis für die Benutzeroberfläche KDE große Verbreitung erreicht hat. Die aktuelle Version erhalten Sie unter www.troll.no. Die über 420 Klassen in mehr als 800 Dateien sind mit einfachen Werkzeugen nur äußerst schwer zu überblicken.

Abbildung [*] zeigt etwa den Projekteditor beim Browsen durch die Bibliothek. Im unteren Teil wird die Hierarchie der Projekte deutlich. Wie Sie hieran sehen, ist SNiFF+ auch gut geeignet, um bestehende Programme und Bibliotheken zu analysieren. Sie geben nur das oberste Verzeichnis an, unter dem der Code der Software steht, und alles andere wird automatisch ermittelt.

Figure: Der Projekteditor von SNiFF+ zeigt die Dateien aller ausgewählten Projekte und deren Hierarchien an.



\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff_proj.eps}

Die Verzeichnisse der Projekte müssen nicht dieselbe Anordnung haben. Es kann sogar sinnvoll sein, ein Projekt bewusst außerhalb der sonstigen Hierarchie anzulegen und es dann an verschiedenen Stellen als Unterprojekt einzufügen.

Arten von Projekten

Man unterscheidet zwei Arten von Projekten:

Bestandteile eines Projekts

Die Makefiles können Sie entweder von SNiFF+ automatisch generieren lassen oder eigene schreiben. Es wird von Ihrem konkreten Projekt abhängen, für welche Möglichkeit Sie sich entscheiden. Ich habe bislang nur gute Erfahrungen mit den automatisch erzeugten Makefiles gemacht.

Zu jedem Projekt gehören außer der Projektbeschreibungsdatei (project description file, PDF) und der Make-Datei noch ein Unterverzeichnis .sniffdir, in das alle Hilfsdateien von SNiFF+ geschrieben werden, zum Beispiel solche zur Verfolgung der Abhängigkeiten von Header-Dateien. Durch den Punkt vor dem Verzeichnisnamen bleibt es bei einem normalen ls-Kommando unsichtbar und hat für Sie als Benutzer auch sonst keine große Bedeutung.

Einstellungen für ein Projekt

Die projektspezifischen Einstellungen heißen in SNiFF+ Attribute. Sie können Sie entweder separat für jedes Projekt einzeln oder auch für mehrere zusammen festlegen. Dazu wählen Sie zunächst aus dem unteren Bereich des Projekteditors das entsprechende Projekt aus oder selektieren mehrere, so dass bei diesen der grüne Haken erscheint. Für das einzelne Projekt rufen Sie nun PROJECT | ATTRIBUTES OF PROJECT <Projektname> auf, für mehrere PROJECT | ATTRIBUTES OF CHECKMARKED PROJECTS. Damit erhalten Sie einen umfangreichen Dialog, auf dessen verschiedenen Seiten Sie alle Optionen für Ihre Projekte einstellen können. Die verschiedenen Themen sehen Sie auf der linken Seite nach Kategorien gegliedert; durch einen Klick auf einen Begriff zeigen Sie die zugehörige Dialogseite an.

Die Dialoge für eines und die für mehrere Projekte sehen weitgehend gleich aus. Der Unterschied liegt nur darin, dass Sie bei mehreren Projekten noch eine Listbox mit allen angekreuzten Projekten auf der rechten Fensterseite sehen. Möchten Sie eine Einstellung für alle Projekte gleichzeitig vornehmen, so müssen Sie das kleine Kästchen hinter der Eingabe abhaken und SET FOR ALL anklicken. Da Sie bereits im Projekteditor eine Vorauswahl getroffen haben sollten, ist nur die Übernahme für eines oder für alle Projekte möglich.

Figure: Im Dialog für Projektattribute können Sie die Einstellungen auch für mehrere Projekte übernehmen.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff-attrib.eps}}



Unter GENERAL gibt es nicht viel, was Sie im Nachhinein noch ändern sollten. Das meiste (und das ist vorwiegend Name und Pfad) geben Sie bereits beim Anlegen des Projekts an.

Bei den BUILD OPTIONS haben Sie zunächst die Möglichkeit, die Make-Unterstützung von SNiFF+ an- und abzuschalten. Wenn Sie sie allerdings einmal abgeschaltet haben, werden Sie auch eigene Make-Dateien geschrieben haben; eine erneute Aktivierung ist dann meist nicht sinnvoll (siehe auch Seite [*]).

Die DIRECTIVES dienen dazu, Anweisungen für den C++-Präprozessor festzulegen. SNiFF+ erkennt selbstständig, wenn ein Projekt Header-Dateien eines anderen Projekts (unterhalb desselben Hauptprojekts) verwendet. Durch einen Klick auf GENERATE können Sie Anweisungen für den Compiler erzeugen (Switches mit -I, zum Beispiel -I../zlib), damit er dieses andere Verzeichnis bei der Suche nach Headern berücksichtigt. Mit EDIT können Sie diese Liste aber auch selbst bearbeiten. Über die weiteren Eingabefelder können Sie zusätzliche Präprozessor-Anweisungen einstellen.

In den PROJECT TARGETS geben Sie an, was das endgültige Zielobjekt dieses Projekts sein soll. Beachten Sie, dass Sie dabei nur genau ein Ziel eintragen dürfen. Projekte mit mehreren Zielen können Sie darüber nicht verwalten. Als Zielarten stehen zur Verfügung:

Zusätzlich können Sie unter +LIBRARIES LINKED noch weitere statische Bibliotheken angeben, die beim Linken des Ziels mit eingebunden werden sollen.

Den Abschnitt BUILD STRUCTURE benötigen Sie insbesondere bei hierarchisch aufgebauten Projekten. Unter PASSED TO SUPERPROJECT legen Sie fest, von welcher Art das Ergebnis sein soll, das Sie an das übergeordnete Projekt weitergeben wollen. Möglich sind:

Die Zeile RECEIVED FROM SUBPROJECTS wird von SNiFF+ meist automatisch ausgefüllt, ebenso wie die RECURSIVE MAKE DIR(S). Wenn Sie wollen, können Sie aber natürlich auch darauf Einfluss nehmen.

Die Seite ADVANCED enthält ein paar Einstellungen, die Sie in die Lage versetzen, SNiFF+ noch ein bisschen detaillierter zu steuern. Meist wird es nicht nötig sein, dass Sie dort Änderungen vornehmen.

SNiFF+ verwendet einen intelligenten Parser, um den Code zu analysieren und beispielsweise farblich zu kennzeichnen. Die Arbeitsweise dieses Parsers können Sie ebenfalls bei Bedarf anpassen. Die Kategorie PARSER enthält dazu einige Eingabeelemente. Eine genaue Diskussion der Möglichkeiten würde diesen Rahmen leider sprengen; ziehen Sie also bitte für nähere Informationen die Original-Dokumentation zu Rate.

Auf der Seite VERSION CONTROL SYSTEM können Sie wählen, ob und wenn ja, welches Revisionskontrollsystem Sie einsetzen wollen. Unter Linux stehen standardmäßig RCS (siehe Seite [*]) und CVS zur Verfügung. Weitere lassen sich allerdings integrieren.

Wichtiger ist wieder die Seite FILE TYPES. SNiFF+ nimmt nur die Dateitypen in die Projektverwaltung auf, die in der Liste auf dieser Seite eingetragen sind. Wenn Sie also einen Dateityp verwenden möchten, der nicht in der Liste vorkommt (zum Beispiel HTML für Dokumentationen), müssen Sie ihn hier eintragen. Klicken Sie zunächst auf SHOW ALL. Damit wird die Liste um alle Typen erweitert, die SNiFF+ kennt. Derzeit unbenutze sind kursiv dargestellt. Um einen Typ in Ihr Projekt aufzunehmen, wählen Sie ihn aus und aktivieren dann ADD FILE TYPE. Kommt der von Ihnen gewünschte Typ überhaupt nicht in der Liste vor, können Sie mit NEW auch einen neuen anlegen.

Für jeden Typ gibt es noch eine Reihe von Einstellungen im unteren Teil des Fensters. Dazu gehören die Endungen, über die er identifiziert werden kann, das Kontextmenü, das im Projekteditor dafür erscheint, das dateitypspezifische Makefile sowie Einstellungen für den Parser. Wenn Sie mit den Voreinstellungen etwas experimentieren, werden Sie schnell die Bedeutung der einzelnen Eingabefelder verstehen.

Intelligente Browser

Wenn Sie in einem größeren Softwareprojekt arbeiten, werden Sie häufiger vor der Aufgabe stehen, sich in Code einzuarbeiten, den ein anderer geschrieben hat. Bei einzelnen Funktionen oder kleinen Klassen kann man sich schnell einen Überblick verschaffen; handelt es sich allerdings um eine größere Zahl von Dateien, die viele Klassen enthalten, fällt es Ihnen sicher schwer, sich mit einfachen Mitteln über die gegenseitigen Abhängigkeiten zu informieren.

Unter anderem für diesen Zweck enthält SNiFF+ eine Reihe intelligenter Browser, mit denen Sie Code analysieren und Verbindungen aufdecken können. Die meisten dieser Werkzeuge erreichen Sie aus allen Fenstern von SNiFF+ im am weitesten links stehenden Menü, das in der Leiste nicht mit einem Wort, sondern mit einem Symbol gekennzeichnet ist.


Der Symbolbrowser

Wenn Sie den Symbolbrowser aufrufen (Abbildung [*]), erhalten Sie eine alphabetisch geordnete Liste aller Bezeichner, die im gesamten Projekt vorkommen. Durch Farben und Kürzel in der ersten Spalte werden die verschiedenen Arten unterschieden; so ist beispielsweise mit cl eine Klasse und mit mi eine inline implementierte Methode gemeint. Durch einen Doppelklick auf den Begriff wird der Editor an dessen Definitionsstelle geöffnet. Sie verwenden den Symbolbrowser vorwiegend, um einen bestimmten Bezeichner, vom dem Sie nur den Namen wissen, schnell aufzufinden.

Figure: Der Symbolbrowser kann alle Bezeichner der Projekte auflisten.



\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff_symbolb.eps}

Da bei großen Projekten die Liste ziemlich lang werden kann, stehen Ihnen mehrere Möglichkeiten zur Einschränkung der Anzeige zur Verfügung. Mit der Auswahlfläche unter der Werkzeugleiste lassen sich nur bestimmte Elemente wie Klassen oder Variablen selektieren. Noch präziser geht es über den Dialog, der durch die Schaltfläche FILTERS erreichbar ist. Natürlich ist auch die Einschränkung auf Namen und Namensteile verfügbar. Im unteren Teil können Sie zudem durch Setzen und Löschen der grünen Häkchen bestimmen, aus welchen Projekten Symbole in die Betrachtung einbezogen werden sollen.


Der Klassenbrowser

Ähnlich wie der Symbolbrowser dient der Klassenbrowser dazu, alle Elemente aufzulisten -- dieses Mal alle, die zu einer Klasse gehören. Es gibt wie immer verschiedene Wege, diesen Browser zu starten; sie gelangen zum Beispiel dahin, wenn Sie im Symbolbrowser eine Klasse auswählen und dann den Menüpunkt CLASS | BROWSER <Klassenname> aufrufen.

An dieser Stelle gleich ein Hinweis: Bei vielen Menüeinträgen werden Sie am rechten Ende ein Tastenkürzel entdecken. Beim Aufruf für den Klassenbrowser heißt es beispielsweise $\times$b. Unter Linux ist mit dem Kreuz die Alt-Taste gemeint. In diesem Fall müssen Sie also Alt+b drücken.

Im Klassenbrowser sehen Sie alle Bestandteile, die eine Klasse enthält; neben Datenelementen und Methoden können dies auch weitere Klassen oder Strukturen, friend-Elemente oder Konstanten sein. Auch hier können Sie wieder die Anzeige auf bestimmte Elemente wie Methoden oder Konstruktoren einschränken. Zudem können Sie im unteren Fensterbereich entscheiden, ob Sie auch die ererbten Elemente aus den Basisklassen sehen möchten oder nicht.

Figure: Der Klassenbrowser zeigt alle Bestandteile einer Klasse und ihrer Basisklassen an.



\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff_classb.eps}



Farbige Symbole deuten an, ob das jeweilige Element public (gelb), private (schwarz) oder protected (türkis) ist. Zudem sind private Elemente von Basisklassen mit grauer Schrift dargestellt, um ihr Unzugänglichkeit zu verdeutlichen. Normale Methoden und Attribute sind durch ein Quadrat gekennzeichnet, virtuelle durch einen diagonalen Balken.

Standardmäßig bekommen Sie nur die Namen der Attribute und Methoden zu Gesicht. Wenn Sie sich für deren genaue Signatur interessieren, müssen Sie das Kästchen SIGNATURE am unteren Rand des Fensters aktivieren. Daraufhin werden alle Attribute mit ihrem Typ angezeigt, alle Methoden mit Rückgabewert und Argumentliste.


Der Hierarchiebrowser

Zu jedem Analysewerkzeug für objekorientierten Code gehört auch eine Anzeigemöglichkeit für Klassenhierarchien. Der in SNiFF+ integrierte Hierarchiebrowser bietet wieder einiges mehr. Neben der vollständigen Klassenhierarchie haben Sie auch die Möglichkeit, sich nur die Nachbarn einer Klasse anzeigen zu lassen, also die Basisklassen und die davon unmittelbar oder mittelbar abgeleiteten Klassen. Sie erreichen diesen Browser, indem Sie in einem der genannten Werkzeuge oder im Editor eine Klasse auswählen und entweder im Kontextmenü oder im CLASS-Menü einen der beiden folgenden Punkte wählen:

Beim ersten Befehl erfahren Sie die Position dieser Klasse innerhalb der gesamten Hierarchie aller Klassen, mit dem zweiten sehen Sie nur die Vorfahren und Nachkommen. Beides kann zu verschiedenen Zwecken nützlich sein. Abbildung [*] zeigt die gesamte Hierarchie.

Figure: Die Querverbindungen in einer Klassenhierarchie lassen zuweilen etwas längere Verbindungslinien entstehen.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff_hierarchyb.eps}}



Auch dieses Fenster besteht wieder aus mehreren Teilen. Auf der linken Seite ist die eigentlich Hierarchie abgebildet. Hier sind die Basisklassen alphabetisch von oben nach unten sortiert. Auf der rechten Seite befindet sich oben eine Liste aller Klassen; durch einen Klick darauf springt die Hierarchie-Anzeige zu dieser Klasse. Darunter ist die Liste der Projekte, die in die Anzeige einbezogen werden. Wenn Sie die Klassen eines Projekts nicht sehen möchten, löschen Sie einfach das grüne Häkchen. Der untere Teil des Fensters enthält den Quelltext, in dem die gerade ausgewählte Klasse deklariert wird. Das Kontextmenü bringt Sie von dort in den Editor, der mit dieser Codestelle geöffnet wird.


Abhängigkeiten von Header-Dateien

Ein weiteres hilfreiches Werkzeug dient der Anzeige der Abhängigkeiten zwischen Header-Dateien. Denn wenn eine Datei eine andere, diese wieder eine dritte usw. einbindet, geht schnell die Übersicht, was in die Übersetzung eigentlich alles einfließt und was dazu nötig ist, schnell verloren. Dieser Browser ist fast genauso aufgebaut wie der für Klassenhierarchien. Sie erreichen ihn unter anderem aus dem Editor, wenn Sie einen der Menüpunkte

wählen. Im ersten Fall sehen Sie alle Header-Dateien, die diese Datei selbst einbindet, im zweiten Fall Dateien, von denen die aktuelle Datei eingebunden wird. Im Feld DEPTH können Sie dabei die Tiefe der Anzeige bestimmen. Ab drei wird die Anzeige meist ziemlich unübersichtlich. Wollen Sie die Abhängigkeiten einer bestimmten Datei verfolgen, klicken Sie diese in der Grafik an und wählen entweder INCLUDES oder IS INCLUDED-BY aus ihrem Kontextmenü.

Editieren, Kompilieren und Debuggen

Die Kerntätigkeiten beim Programmieren sind ja Schreiben des Programms, Kompilieren und Debuggen -- und das im Zyklus. Eine integrierte Entwicklungsumgebung muss also zuvorderst diese Abläufe unterstützen. Wie Sie gleich sehen werden, steht Ihnen SNiFF+ hierbei zuverlässig zur Seite.


Editor

Der Editor von SNiFF+ ist sehr bequem zu bedienen, wenn auch am Anfang etwas gewöhnungbedürftig. Auf der rechten Seiten finden Sie ein eingebettetes Fenster, das alle Symbole dieser Datei enthält, also Klassen, Methoden und so weiter. Der Auswahlknopf darüber schränkt die Anzeige auf bestimmte Klassen ein. Die Symbole sind -- wie auch schon in den anderen Browsern -- durch verschiedene Textfarben voneinander abgehoben, beispielsweise Klassen grün, normale Methoden dunkelrot, inline-Methoden hellrot und Funktionen schwarz.

Figure: Der Editor in SNiFF+ dient gleichzeitig zum Navigieren.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff_editor.eps}}

Viel Funktionalität ist hier über das Menü verfügbar, fast noch mehr über die jeweiligen Kontextmenüs. So können Sie beispielsweise aus der Liste der Bezeichner durch den entsprechenden Befehl sehr leicht zwischen Deklaration und Implementierung von Klassen und Methoden hin- und herspringen.

Achtung: \resizebox{10mm}{!}{\includegraphics{images/vorsicht.eps}} Die im Kontextmenü des Editors angebotenen Funktionen, zu einem beliebigen Bezeichner alle Stellen zu ermitteln, auf die sich dieser Bezeichner bezieht (zum Beispiel QTEXTBOX REFERS-TO), oder alle, wo er selbst verwendet wird (etwa QTEXTBOX IS REFERRED BY), ist in der freien Penguin-Edition von SNiFF+ nicht verfügbar. Dazu bedarf es dann doch der kommerziellen Variante.

Anfangs ungewohnt ist der Umgang mit mehreren Dateien. Anders als in den meisten Editoren (beispielsweise auch im XEmacs) ist in SNiFF+ keine Liste aller gerade offenen Dateien verfügbar. Dafür bietet das Menü HISTORY eine Liste aller zuletzt angesprungenen Codestellen, wie in einem Web-Browser. Entsprechend kommen Sie auch mit der ZURÜCK-Schaltfläche an die von Ihnen zuletzt bearbeitete beziehungsweise angesprungene Stelle; dies kann in der gleichen Datei wie Ihre aktuelle Position liegen oder in einer anderen.

Die Syntaxeinfärbung unterscheidet nach Kommentaren, Funktions- und Methodennamen, Präprozessor-Anweisungen und anderem. Sie wird nicht unmittelbar beim Tippen aktualisiert, sondern erst beim Abspeichern. Dafür ist der verwendete Parser sehr flexibel und kann auch mit unvollständigem und inkorrektem Code umgehen. Die Syntaxeinfärbung arbeitet übrigens nur für Dateien, die zum Projekt (oder einem seiner Unterprojekte) gehören. Wenn Sie eine andere C++-Datei über FILE | OPEN laden, erscheint dieses schwarz-weiß.

Die wichtigste Aktion beim Tippen ist meist das Abspeichern. Wenn Sie dafür nicht extra die Hände von der Tastatur nehmen wollen, um die Maus zu bedienen, können Sie auch mit Alt+s oder -- wie beim XEmacs -- mit Strg+x, Strg+s die aktuelle Datei speichern.

Andere Aktionen lassen sich mit Tastenkombinationen erledigen, die eher von Windows vertraut sind: Alt+x oder $\Uparrow$+Entf zum Ausschneiden und Alt+c oder Strg+Einfg zum Kopieren; weiterhin Alt+v oder auch $\Uparrow$+Einfg zum Einfügen, Alt+z für Rückgängig. Mit etwas Übung gehen auch diese leicht von der Hand.

Auch der Zugang zum Konfigurationsmanagement ist in den Editor integriert. Wollen Sie eine Datei, die noch eingecheckt ist, bearbeiten, weist Sie SNiFF+ darauf hin und erledigt das Auschecken. Manuell können Sie diese Dienste auch über das FILE-Menü erreichen (CHECK IN, CHECK OUT, LOCK, UNLOCK). Möchten Sie zu einer Datei allerdings die komplette Versionsgeschichte sehen, müssen Sie den Projekteditor verwenden. Wählen Sie die Datei im mittleren Feld aus und klicken dann auf das Kontrollkästchen HISTORY am unteren Rand; es erscheint ein zusätzliches Fenster, in dem Sie die Liste der Revisionen erkennen können.

Andere Editoren

Das offene Konzept von SNiFF+ erlaubt Ihnen, auch andere Editoren zu verwenden, wenn Sie der Meinung sind, mit diesen besser arbeiten zu können. Standardmäßig unterstützt SNiFF+ als Alternativen (X)Emacs (Seite [*]) und VIM, einen verbesserten vi (Seite [*]).

Um beispielsweise den XEmacs als Editor zu verwenden, müssen Sie folgendermaßen vorgehen:

  1. Starten Sie XEmacs aus einer separaten Shell oder über den Desktop.
  2. Laden Sie das SNiFF-Lisp-Programm. Dies finden Sie in der Datei $SNIFF_DIR/config/sniff-mode.el. Das Laden können Sie anfangs von Hand über Alt+x und load-file erledigen; später können Sie dieses Kommando in Ihre Datei .emacs eintragen.
  3. Starten Sie SNiFF+. (Es darf aber auch schon vorher laufen.)
  4. Verbinden Sie den Editor mit SNIFF+, indem Sie im XEmacs erst Alt+x und drücken und dort sniff-connect eingeben.
  5. Um den verwendeten Editor in SNiFF+ einzustellen, rufen Sie das Sniff-Menü ganz links auf und wählen daraus PREFERENCES. Unter der Kategorie SOURCE EDITOR stellen Sie CURRENT EDITOR dann auf Emacs/Vim.
  6. Wenn Sie nun eine Datei mit SNiFF+ zum Editieren öffnen, etwa durch einen Doppelklick im Projekteditor, erscheint diese im XEmacs. Weitere Funktionen, die sonst im Editor integriert sind, erreichen Sie im XEmacs über das Menü SNIFF.
Obwohl das Zusammenspiel nicht immer ganz reibungslos klappt und man doch ein wenig Funktionalität gegenüber dem eingebauten Editor einbüßt (vor allem beim Debuggen), ist dieser Weg für alle empfehlenswert, die den XEmacs sehr gut beherrschen und daher keine Notwendigkeit zum Umstieg sehen.

Da hier nur ein relativ einfaches Lisp-Programm die Verbindung regelt, funktioniert dieses Zusammenspiel in genau derselben Weise auch mit dem GNU Emacs. Für VIM gibt es ebenfalls eine Konfigurationsdatei, nämlich $SNIFF_DIR/config/sniff.vim; auch dort ist ein sniff-connect zum Aufbau der Verbindung nötig. Ansonsten geht alles analog zum XEmacs.


Der Make-Support

Bei jedem Projekt, das aus mehr als einer Datei besteht, kommt man unter Linux um ein Makefile fast nicht herum. Wenn Sie sich aber mit dem ab Seite [*] beschriebenen Werkzeug make nicht so ganz wohl fühlen, ist SNiFF+ für Sie ein Ausweg. Auf der einen Seite unterstützt es natürlich selbst geschriebene Makefiles, auf der anderen erzeugt es diese aber auch automatisch für Sie, so dass Sie sich um nichts mehr kümmern müssen.

Bei einem bestehenden Projekt können Sie recht leicht die Make-Unterstützung abschalten; das Einschalten ist da schon erheblich problematischer und wenig empfehlenswert. Besser ist es da, wenn Sie gleich bei der Erzeugung des Projekts entscheiden, ob Sie den Automatismus oder die Handarbeit vorziehen. Gewisse Eingriffsmöglichkeiten bleiben Ihnen aber trotzdem.

Sie erkennen die aktuelle Einstellung auf der Seite BUILD OPTIONS der Projektattribute (erreichbar im Projekteditor durch Anklicken des Projekts und PROJECT | ATTRIBUTES OF PROJECT). Wenn dort das Kontrollkästchen USE SNIFF+ MAKE SUPPORT aktiviert ist, werden die Make-Dateien automatisch erzeugt. Da Sie dieses Fenster auch ausfüllen, wenn Sie ein neues Projekt anlegen, ist das also der Platz, an dem Sie sich zwischen automatischer und manueller Verwaltung der Makefiles entscheiden müssen.

Wenn Sie die Struktur Ihrer Projekte ändern, also Dateien hinzufügen oder entfernen, müssen Sie die jeweiligen Makefiles aktualisieren. Dazu klicken Sie im Projekteditor das Projekt an und wählen UPDATE MAKEFILES aus dessen Kontextmenü. Beim Bestätigungsdialog (Abbildung [*]) haben Sie dann noch Gelegenheit anzugeben, ob Sie auch die Hilfsdateien mit den Abhängigkeiten im Unterverzeichnis .sniffdir aktualisieren wollen. Da dies fast immer sinnvoll ist, sollten Sie dieses Kästchen stets aktiviert lassen.

Figure: Die Aktualisierung der Makefiles müssen Sie bestätigen.



\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff-upd.eps}

Wenn Sie einen Blick auf die automatisch erzeugten Make-Dateien werfen, muten diese etwas merkwürdig an. Sie bestehen fast nur aus Kommentaren und Makrodefinitionen. Wo sind aber die Regeln? SNiFF+ arbeitet mit einer ganzen Reihe von ineinander verschachtelten Make-Dateien:

Beachten Sie außerdem, dass die SNiFF+-Make-Dateien einige zusätzliche Umgebungsvariablen voraussetzen. Bei der Generierung aus der IDE sind diese automatisch gesetzt. Wenn Sie make aus Ihrer eigenen Shell aufrufen, müssen Sie selbst dafür sorgen.

Neben einem Ziel all enthalten die Makefiles noch die Ziele

Wenn Sie beispielsweise beim Kompilieren stets die Fehlermeldung bekommen, dass Funktionen der C++-Standardbibliothek nicht dazugelinkt werden können, müssen Sie entweder im Plattform-Makefile das Kommando $LINK auf g++ -ldl ändern oder bei den Flags im Projekt explizit die Bibliothek libg++.a angeben.

Kompilieren und Generieren

Das Generieren von Programmen lässt sich in SNiFF+ von vielerlei Orten aus aufrufen. Meist verwenden Sie dazu das Menü TARGET, aus dem Sie dann entweder RECURSIVELY MAKE PROJECT oder MAKE | ALL aufrufen. Wenn ein solcher Punkt vorhanden ist, geht auch MAKE MAIN TARGET.

Daraufhin öffnet sich ein neues Fenster, die Local Shell. In Abbildung [*] sehen diese für unser Sender/Receiver-Projekt von Seite [*].

Figure: Das Shell-Fenster stellt neben normalen Shell-Eigenschaften noch das Menü für den Zugriff auf weitere SNiFF+-Funktionen bereit.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff-shell.eps}}

Die Local Shell ist eine ganz normale Shell, in der Sie auch selbst alle üblichen Befehle eingeben können. (Der Name Local Shell rührt daher, dass SNiFF+ in der größeren Version auch die verteilte Entwicklung über remote shells unterstützt.) Die Shell übernimmt zudem die Voreinstellungen des jeweiligen Benutzers; wenn Sie also üblicherweise die C-Shell verwenden, wird diese auch hier gestartet und Ihre persönlichen Einstellungen aus .cshrc werden geladen.

Ein Unterschied besteht bei der Arbeit mit der Zwischenablage. Um etwas aus diesem Fenster zu kopieren, müssen Sie es erst markieren und dann zusätzlich über EDIT | COPY oder das Kontextmenü in die Zwischenablage bringen.

Tritt ein Fehler beim Generieren auf, klicken Sie darauf und wählen dann aus dem Kontextmenü SHOW ERROR. (Ein einfacher Doppelklick oder Ähnliches genügt leider nicht.) SNiFF+ öffnet nun die entsprechende Datei im Editor und zeigt die fehlerbehaftete Zeile an.

Für besondere Aufgaben gibt es noch den Target-Dialog, den Sie über TARGET | TARGET DIALOG öffnen können. In ihm lassen sich die Ziele separat auswählen und gezielt durch einen Klick auf MAKE erzeugen. Wenn Sie MAKE WITH DEBUG aktivieren, gibt Ihnen SNiFF+ zudem etwas mehr interne Informationen über seinen Make-Prozess aus, so dass Sie Probleme damit leichter lokalisieren können.

Der Debugger

Neben dem Generieren ist auch das Debuggen direkt aus der IDE möglich. Mit TARGET | RUN <Dateiname> können Sie das Programm in der lokalen Shell ausführen. Vor jedem Start erscheint noch ein kleines Fenster, in dem Sie mögliche Argumente für die Kommandozeile eintragen können.

Befürchten Sie Probleme in Ihrem Programm, können Sie mit TARGET | DEBUG <Dateiname> den Debugger starten. Standardmäßig verwendet SNiFF+ unter Linux den gdb (siehe Seite [*], auch zu den Begriffen und Konzepten des Debuggings). Im Debugger-Dialog (Abbildung [*]) erhalten Sie den Zugriff auf die gdb-Kommandozeile. Allerdings können Sie die meisten Befehle auch über Menüs und Buttons erreichen.

Figure: Der Debugger-Dialog lässt Eingaben auf Kommandozeilenebene zu.



\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff-debugger.eps}



Sobald Sie den Debugger aktivieren, erscheint im Editor eine zusätzliche Leiste mit Schaltflächen, über die Sie den Programmablauf steuern können. Neben RUN und CONT sind dies auch STEP, NEXT und BREAK AT (Letzteres zum Setzen eines Haltepunktes). Während des Ablaufs können Sie Ausgaben über Inhalte von Variablen über das Menü DEBUG erreichen. Die PRINT- und DISPLAY-Befehle beziehen sich dabei stets auf die aktuelle Markierung. Über die Schaltfläche Stack erfahren Sie den aktuellen Aufrufstack. Alle Ausgaben erscheinen dabei im Debugger-Dialog. Dort können Sie auch noch weitere Informationen beziehen.

Sie beenden den Debugger, indem Sie dessen Dialog schließen oder über DEBUG | END DEBUG SESSION.

Sie können auch den DDD unter SNiFF+ verwenden (siehe Seite [*]). Im Installationsverzeichnis gibt es einen Unterordner integrations/ddd, der die notwendigen Dateien sowie eine ausführliche Erläuterung enthält. (Diese ist unglücklicherweise im Format Microsoft Word.) Damit können Sie auch die grafischen Elemente des DDD von SNiFF+ aus einsetzen.

Entwickeln im Team

Ein weiteres besonderes Merkmal von SNiFF+ ist, dass es die Softwareentwicklung im Team nicht nur unterstützt, sondern auch mit eigenen Konzepten bereichert. Dazu gehören vor allem die Arbeitsbereiche, engl. working environments. Jeder dieser Bereiche stellt eine Sicht auf den Quellcode dar. Durch Einchecken und Abrufen werden die einzelnen Bereiche untereinander konsistent gehalten.

Überblick

Die Arbeitsbereiche sind hierarchisch organisiert.

Die Zusammenhänge sind dabei recht einfach: Der Entwickler holt sich die Quelltexte aus dem RWE in seinen privaten Bereich (PWE) und arbeitet dort mit diesen. Entweder legt er nur ein Kopie zum Lesen an oder er checkt die Datei aus, damit er sie modifizieren kann. Nach getaner Arbeit checkt er die neue Revision wieder ins Repository ein.

Die Shared-Bereiche sollen vor allem Speicherplatz sparen. Das SSWE wird regelmäßig aus dem RWE aktualisiert, so dass dort immer eine stabile Version liegt. Ebenso regelmäßig wird daraus durch ein rekursives make das SOWE generiert. Wenn ein Entwickler sich die aktuellste Version des Projekts aus dem RWE holen möchte, überprüft SNiFF+, ob es von dieser nicht auch ein Exemplar im SSWE gibt und legt dann statt einer Kopie lediglich einen symbolischen Link an.

Start eines neuen Projekts

Wenn Sie ein neues Projekt anlegen (nennen wir es mal Xenia), ist der erste Schritt, eine eigene Datei einzurichten, in der die Informationen über die Arbeitsbereiche gespeichert werden. Deren Ort teilen Sie SNiFF+ unter PREFERENCES | TOOLS | WORKING ENVIRONMENTS | WORKING ENVIRONMENTS CONFIG. DIRECTORY mit. Diese Datei muss ebenso wie alle gemeinsam genutzten Arbeitsbereiche auf einem Netzlaufwerk untergebracht sein, zu dem alle Entwickler Zugang haben. Die Voreinstellung, dass die Konfigurationsdatei im Installationsverzeichnis von SNiFF+ abgelegt wird, sollten Sie keinesfalls übernehmen; meist haben Sie dort nämlich keine Schreibrechte und können zudem mit anderen Teams in Konflikt kommen, die auch mit SNiFF+ arbeiten wollen.

Dann starten Sie das Werkzeug zur Festlegung der Arbeitsbereiche (Abbildung [*]). Sie finden es unter anderem im SNiFF+-Menü als WORKING ENVIRONMENTS.

Figure: Mit dem entsprechenden Werkzeug kann man die Arbeitsbereiche leicht konfigurieren.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/sniff_we.eps}}


Das Repository Working Environment

Als oberstes Element legen Sie ein RWE an (über EDIT | NEW REPOSITORY). Dort werden die Versionsgeschichten aller Projektdateien abgelegt. Wenn Sie etwa RCS einsetzen, besteht das RWE aus der gleichen Verzeichnisstruktur wie Ihr Projekt, nur dass in jedem Verzeichnis lediglich das Unterverzeichnis RCS existiert, in dem die Archive der Dateien des jeweiligen Ordners abgelegt sind. Für ein Backup Ihres Projekt reicht das RWE also prinzipiell aus. Allerdings sollten Sie sicherheitshalber auch das SSWE sichern.

Aufgrund seiner zentralen Bedeutung muss das RWE für jeden Entwickler erreichbar sein, und zwar auf Dateiebene. Am einfachsten ist es daher, wenn Sie das RWE auf einem exportierten Laufwerk eines Servers einrichten, auf das alle via NFS Zugriff haben. Eine Entwicklung an mehreren Standorten, die nicht durch NFS verbunden sind, wird von SNiFF+ derzeit leider nicht unterstützt.

In der Pfadangabe für das RWE dürfen übrigens auch Umgebungsvariablen stehen. So können Sie Ihre Entwicklungsumgebung von einer konkreten Position im Netz unabhängig halten. Wenn Ihr Laufwerk bespielsweise auf einen anderen Rechner umziehen muss, genügt es, die Shell-Variable zu ändern.


Das Shared Source Working Environment

Das SSWE soll also dazu dienen, eine aktuelle und stabile Version aller Projektdateien verfügbar zu haben. Will der Programmierer nicht gerade Bearbeitungen vornehmen oder frühere Revisionen einbeziehen, genügt es, ihm einen symbolischen Link auf die Dateien des SSWE zu geben. Auf diese Weise kann Speicherplatz in den lokalen Verzeichnissen der Entwickler gespart werden. Das setzt natürlich wieder voraus, dass das SSWE allen per NFS zugänglich ist. Daher bietet es sich an, es in einem parallelen Verzeichnis zum RWE abzulegen.

Um ein SSWE einzurichten, klicken Sie das Repository im Working-Environment-Werkzeug an und wählen EDIT | NEW SHARED SOURCE BASED ON REPOSITORY. Im zugehörigen Dialog geben Sie neben dem Pfad auch einen Namen für das SSWE an. Die anderen Felder werden Sie meist leer lassen.

Um das SSWE zu aktualisieren, gibt es zwei Möglichkeiten: in der IDE oder im Batch-Betrieb. Für die erste klicken Sie doppelt auf den Namen, wählen dann das Projekt aus, das an der Spitze Ihrer Hierarchie steht (eventuell vorher mit UPDATE LIST die Anzeige vervollständigen). Dann sollten Sie im Projekteditor dafür sorgen, dass alle Unterprojekte mit einem Häkchen versehen sind. Anschließend klicken Sie dort auf PROJECT | SYNCHRONIZE CHECKMARKED PROJECTS. Um auch die Makefiles zu aktualisieren, da sie durch Löschen oder Hinzufügen von Dateien inkonsistent geworden sein könnten, wählen Sie zusätzlich TARGET | UPDATE MAKEFILES.

Für den Batch-Betrieb liefert SNiFF+ ein Shell-Skript mit. Dieses finden Sie unter dem Installationsverzeichnis in Form der Datei ws_support/updatedWS.sh. Dieses können Sie beispielsweise nachts über einen cron-Job aufrufen lassen. Das Skript hat drei Argumente: den Namen des Arbeitsbereichs, den des Projekts und den Typ des Arbeitsbereichs, also SSWE, SOWE oder PWE. Es ist nicht allzu schwierig zu durchschauen; daher rate ich Ihnen, dieses Skript zunächst zu analysieren, um alle Erwartungen, die es an Sie stellt, erfüllen zu können. Die Ausgabe der Aktualisierung werden in einer Log-Datei gesammelt, die dem Benutzer, der das Skript aufruft, per E-Mail zugestellt wird.

Um mit dem Projektfortschritt mitzuhalten, sollten Sie eine solche Aktualisierung mindestens einmal täglich durchführen, entweder morgens von Hand oder nachts automatisch.


Das Shared Object Working Environment

Vom SOWE sollte es eines für jede Zielplattform geben. Da das bei der Penguin-Edition nur Linux ist, brauchen Sie dabei nur eines. Wenn Sie ein SOWE anlegen (im Working-Environments-Werkzeug mittels EDIT | NEW SHARED OBJECT BASED ON SSWE, nachdem Sie das zugehörige SSWE ausgewählt haben), haben Sie ebenfalls die Möglichkeit, die Plattform einzustellen. Diese Festlegung macht sich später dadurch bemerkbar, dass SNiFF+ beim Generieren das entsprechende Plattform-Makefile einbindet (siehe Seite [*]).

Die Aktualisierung des SOWE funktioniert genauso wie beim SSWE beschrieben; auch hier sind beide Wege grundsätzlich möglich. Da es sich beim SOWE um einen Arbeitsbereich mit generierten Dateien, also Objektdateien und Bibliotheken handelt, muss hier freilich noch die Kompilierung durchgeführt werden. Beim Skript ist diese bereits enthalten, bei dem Abgleich aus der IDE müssen Sie selbst TARGET | RECURSIVELY MAKE PROJECT aufrufen. Vorher sollten Sie vorzugsweise ein TARGET | MAKE | CLEAN durchgeführt haben. Aufgrund der Abhängigkeiten müssen Sie dafür sorgen, dass die Aktualsierung des SSWE vor der des SOWE durchgeführt wird.


Das Private Working Environment

Das PWE ist schließlich der Arbeitsbereich des Programmierers. Daher sollte ein PWE in einem Home-Verzeichnis angesiedelt sein oder in einem vergleichbaren Bereich, der vor anderen geschützt ist. Sie können ein PWE auf der Basis eines jeden der vorgenannten Arbeitsbereiche einrichten und damit einen oder beide der Shared-Bereiche umgehen. Bei mehreren Entwicklern sind die Shared-Bereiche aber durchaus sinnvoll, so dass Sie Ihr PWE über EDIT | NEW PRIVATE BASED ON SOWE einrichten sollten. Wenn Sie das nicht nur für sich, sondern auch für andere erledigen wollen, sollten Sie darauf achten, in der letzten Zeile des Dialogs den richtigen Benutzer einzutragen.

Auch das PWE aktualisieren Sie wie oben beschrieben. Da auch hier generierte Dateien enthalten sind, müssen Sie wie beim SOWE den Make-Prozess starten. Im Laufe der Aktualisierung gegen das SOWE werden die Objektdateien und Bibliotheken gegebenenfalls gelöscht und durch symbolische Links ins SOWE ersetzt. Wie Sie sicher schon gemerkt haben, gilt auch hier, dass Sie zunächst das SSWE, dann das SOWE und am Ende das PWE aktualisieren müssen.

Das Einchecken von Dateien sollte bei der Arbeit mit SNiFF+ etwas konsequenter gehandhabt werden, als das bei einer einfachen Revisionskontrolle mit RCS sonst nötig ist. Unvollständige oder fehlerhafte Dateien sollten überhaupt nicht eingecheckt werden. Da alle anderen Entwickler die Datei im SSWE rasch sehen, muss sie nicht nur in sich selbst, sondern auch gegenüber anderen konsistent sein, darf also nicht zu Übersetzungsfehlern oder Schnittstellenproblemen führen. Durch mangelnde Sorgfalt in dieser Hinsicht kann nämlich leicht die Generierung im SOWE blockiert werden.

Zusammenfassung

In diesem Abschnitt haben Sie einen ersten Überblick über die integrierte Entwicklungsumgebung SNiFF+ bekommen. Wir haben uns dabei eine ganze Reihe von Funktionsmerkmalen angesehen:

Doch das ist bei weitem nicht alles. Es gibt also noch viel zu entdecken, was SNiFF+ bietet: Ein Konfigurationsmanagementwerkzeug, eine automatische Erzeugung von Online-Projektdokumentation und so weiter. Für ganz Entschlossene steht auch die Programmierschnittstelle in Python zur Verfügung, mit der eigene Erweiterungen geschaffen werden können.

SNiFF+ ist damit eine der ausgereiftesten Entwicklungsumgebungen, die unter Linux zur Verfügung stehen. Da die C++-Ausgabe sogar kostenlos erhältlich ist, kann dieses Produkt nur empfohlen werden. Schade ist, dass der Cross-Referencer in der Penguin-Edition nicht enthalten ist; mit ihm wäre ein tatsächlich inhaltsabhängiges Navigieren möglich. Ein Defizit aller Versionen bleibt die Online-Hilfe; sie ist (trotz der verschiedentlichen HELP-Schaltflächen) keineswegs kontext-sensitiv und besteht vorwiegend aus einer HTML-Version der gedruckten Handbücher. Ein Index fehlt fast völlig, eine Stichwortsuche müsste man sich mit Werkzeugen wie htDig selbst erzeugen. Hier bleibt zu hoffen, dass sich die Verhältnisse mit einer der nächsten Ausgaben bessern.


Weitere Entwicklungsumgebungen

Auch wenn die traditionellen Programmierwerkzeuge unter Unix aus Editor, Make und Kommandozeilencompiler bestehen, ist SNiFF+ keineswegs die einzige komplette IDE, die es unter Linux gibt. In diesem Abschnitt will ich Ihnen drei weitere vorstellen, die zumeist ähnliche Ansätze verfolgen und daher ebenso leicht erlernbar sind.

Es sind dies:

Kommerziell ist mittlerweile nur noch der zweite, das heißt nicht kostenlos erhältlich. Nach der Übernahme von Cygnus hat sich RedHat entschieden, den Source Navigator frei unters Volk zu bringen.


Source Navigator

Der Source Navigator bietet einen Großteil der Funktionalität von SNiFF+, ist allerdings etwas weniger bunt. Sie können ihn direkt bei RedHat herunterladen (sources.redhat.com/sourcenav/) -- oder von beiliegender CD-ROM installieren.

Die Arbeit damit findet vorwiegend in zwei Fenstern statt:

Figure: Das Hauptfenster des Source Navigator enthält neben dem Editor auch die meisten Browser.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/snav.eps}}

Zur Organisation der Projekte bietet der Source Navigator zudem einen eigenen Projekteditor, in dem sich die Abhängigkeiten in Baum-Ansicht darstellen und organisieren lassen. So wird schnell ersichtlich, welche Datei zu welchem Projekt gehört und wo Projekte ineinander greifen. Ein schönes Feature ist die Statistik. Durch einen Klick auf diese Schaltfläche erfahren Sie, wie viele Dateien, Klassen, Funktionen, Methoden usw. ein Projekt enthält.

Die Generierung findet hier in einem eigenen Dialog statt, der ähnlich wie beim XEmacs nur die Ausgaben von Make sammelt und keine Eingaben auf Shell-Ebene erlaubt. Bei Fehlern kann zurück zum Code gesprungen werden. Als Debugger ist standardmäßig der gdb integriert.


CodeWarrior

CodeWarrior von Metrowerks kam als erstes für den Apple Macintosh auf den Markt und war lange Zeit die wichtigste IDE auf dieser Plattform. Mittlerweile gibt es auch Portierungen für andere Betriebssysteme, seit kurzem auch für Linux (siehe www.metrowerks.com/desktop/linux/).

Auffallend gegenüber allen anderen hier vorgestellten Entwicklungsumgebungen ist, dass CodeWarrior nicht unabhängig von der verwendeten Linux-Distribution ist. Er ist vielmehr in einer Ausgabe für RedHat Linux und einer für SuSE Linux erhältlich. Gegenwärtig arbeitet der CodeWarrior noch mit dem GCC; Metrowerks plant allerdings auch ein Portierung ihres eigenen Compilers. Außerdem ist das Programm nicht kostenlos, sondern muss käuflich erworben werden!

Die Bedienparadigmen des Mac sind noch an ein paar Stellen des CodeWarrior offensichtlich. So erhalten Sie unmittelbar nach dem Start kein vollständiges Fenster, sondern lediglich ein Fensterchen, das nur aus einer Menüleiste besteht. Über diese lassen sich dann alle weiteren Kommandos aufrufen.

Wenn Sie über FILE | NEW PROJECT ein neues Projekt öffnen, haben Sie neben einem völlig leeren Projekt auch die Möglichkeit, über eine Vorlage schon ein (meist sehr einfaches) Gerüst erzeugen zu lassen.

Vorbildlich sind die Projekteinstellungen (Abbildung [*]): Für jeden Dateityp lässt sich (prinzipiell) ein eigenes Übersetzungswerkzeug definieren. Leider steht in dieser Version nur der GCC zur Verfügung. Auch Compileroptionen und Pfade lassen sich damit sehr einfach setzen.

Figure: Die Projekteinstellungen beim CodeWarrior sind ebenso übersichtlich wie vielseitig.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/cw-settings.eps}}



Oftmals hat die IDE aber das Problem, dass ihre Schrift auf einem Bildschirm höherer Auflösung sehr klein wirkt. Neben den Einstellungen sind auch der Projekteditor und der Klassenbrowser davon betroffen.

An höheren Werkzeugen verfügt der CodeWarrior über einen Hierarchiebrowser, einen Klassenbrowser und einen Symbolbrowser. Die Abhängigkeiten der Header-Dateien werden über eine kleine Schaltfläche im Projekteditor sichtbar gemacht.

Die Übersetzung erfolgt in der Shell, aus der man die IDE (übrigens mittels cwide) gestartet hat. Die Ausgaben laufen dann allerdings wieder in ein eigenes ERROR & WARNINGS-Fenster. Selbst Sonderfunktionen des GCC wie separater Syntaxcheck oder alleiniges Preprocessing sind aus der IDE aufrufbar.

Der Editor erfüllt alle Anforderungen, die man beim Programmieren braucht, hat eine vernünftige Syntaxeinfärbung und erlaubt leichtes Navigieren. Unterstützt wird dieses besonders durch Lesezeichen, die man im Code anbringen kann. Auch der Sprung zwischen den Funktionen und Methoden wird durch ausklappbare Listen erleichtert. Eine Anbindung an die Versionsverwaltung gibt es ebenso. Wer darauf verzichten möchte, darf auch hier einen externen Editor verwenden.

Die Debugger-Anbindung glänzt durch eine ganze Reihe von Ausgabefenstern, etwa für Prozesse, Ausdrücke, globale Variablen oder Haltepunkte. Andererseits ist auch die Einbindung eines externen Debuggers wie des DDD ohne weiteres möglich.

Insgesamt unterscheidet sich der CodeWarrior in seinem Funktionsumfang nicht grundsätzlich vom Source Navigator oder von SNiFF+. Da er im Gegensatz zu den beiden anderen aber nicht kostenlos angeboten wird, ist er wohl eher für Entwickler geeignet, die damit schon einige Erfahrung haben und beim Plattformwechsel ihr Werkzeug weiter verwenden wollen.


KDevelop

Auch das KDE-Projekt hat mit KDevelop eine eigene integrierte Entwicklungsumgebung hervorgebracht. Wie alles in KDE steht auch diese unter GPL und ist frei im Quelltext verfügbar. Die aktuellste Version erhalten Sie stets von www.kdevelop.org.

Das Programm ist mittlerweile zu einer sehr komfortablen IDE herangereift. Besonders hervorzuheben ist zunächst die gute Online-Hilfe, die für ein Open-Source-Projekt ja nicht selbstverständlich ist. Neben einem Benutzer- und einem Entwickler-Handbuch ist auch ein Tutorial und eine C/C++-Referenz sowie eine KDE-Bibliotheksreferenz verfügbar -- und das zum Teil in mehreren Sprachen! Für Einsteiger hilfreich ist auch der Tipp des Tages, der auf Wunsch bei jedem Start von KDevelop erscheint.

Figure: Über das Hauptfenster von KDevelop sind Header, Implementationsdateien, Dokumentation und Werkzeuge erreichbar.



\resizebox*{1\columnwidth}{!}{\includegraphics{/usr/homes/thomas/cpp/cpp_linux/Text/images/kdevel.eps}}

Wenn Sie nach der Installation des rpm-Paketes oder aus dem übersetzten Source-Code KDevelop das erste Mal aufrufen, müssen Sie noch einige Einstellungen festlegen. So können Sie beispielsweise wählen, ob Sie für Hervorhebungen eher den Stil des Emacs oder den von KWrite wünschen. (KWrite (siehe auch Seite [*]) ist der Standard-Editor von KDevelop, der aber nahtlos integriert ist.) Anschließend prüft die Installationsroutine Ihr System und weist Sie gegebenenfalls auf fehlende Programme oder Dokumentationen hin, die Sie bei Ihrer Arbeit mit KDevelop brauchen könnten.

Ausgereift stellt sich auch der Projekt-Wizard dar (erreichbar über den Menüpunkt PROJEKT | NEU). Hier können Sie Gerüste für Projekte nach Ihren Vorgaben erzeugen lassen, auf denen Sie dann aufbauen können. Neben der Konsolenapplikation stehen vorwiegend KDE- und Qt-Anwendungen als Ausgangspunkte zur Auswahl. In den Seiten des Wizards können Sie neben Pfad und Dateinamen auch die CVS-Unterstützung und die Vorlage für die Dateiköpfe konfigurieren. Der Nachteil dieses Assistenten ist, dass er fast zu viel kann. Sie erhalten damit das Gerüst für ein vollständiges GNU-Softwareprojekt, einschließlich README, Lizenzhinweise, Makefile und configure-Skript. Selbst bei einer Konsolenanwendung kommen so an die 100 (!) Dateien zusammen, bevor Sie überhaupt eine Zeile Code geschrieben haben. Für den im Umgang mit GNU- und KDE-Projekten erfahrenen Entwickler ist das sicherlich sehr hilfreich; für einen Anfänger dagegen höchst verwirrend. Sie müssen nämlich bereits wissen, was diese Dateien alle für eine Bedeutung haben, bevor Sie mit KDevelop umgehen.

Das Hauptfenster von KDevelop (Abbildung [*]Fig:KDevelop) mag auf den ersten Blick etwas vollgestopft erscheinen. Da die Funktionsweise und Aufgabengebiete aber klar gegliedert sind, werden Sie sich sicher schnell zurecht finden. Auf der linken Seite können Sie zwischen verschiedenen Baum-Ansichten umschalten, die einmal nach Klassen, Strukturen, Namensräumen und so weiter aufgebaut sind, ein anderes Mal nach Dateien und deren Typen sowie ein drittes Mal nach Dateien und Verzeichnissen. Unter dem vierten Reiter finden Sie die Dokumentation (auch die Ihres eigenen Projekts, sobald Sie eine solche geschrieben haben). Der Hauptteil in der Mitte rechts stellt den Editor dar, wobei zwischen Header- und Implementationsdateien unterschieden wird. Dort erscheinen aber auch die Dokumentation sowie die sehr harmonisch integrierten Anwendungen Kdgb, KIconEdit sowie KPaint. Im unteren Teil, der Ausgabeansicht, können Sie die Ausgaben der externen Programme wie make, gdb sowie Ihres eigenen ablesen.

Sehr eng gekoppelt mit GCC und make sind auch die Projekteinstellungen, dafür aber nicht weniger komfortabel. Unter PROJEKT | OPTIONEN erreichen Sie einen Dialog, in dem Sie auf mehreren Seiten Compileroptionen setzen, Warnungen aktivieren, Bibliotheken hinzufügen sowie diverse Flags für make setzen können.

Der Editor hält sich an alle Konventionen, die Sie aus anderen Programmen für KDE kennen. So können Sie mit Strg+X ausschneiden, mit Strg+Z die letzte Aktion rückgängig machen, mit Strg+S speichern und so fort. Die Syntaxeinfärbung ist übersichtlich, ein automatisches Einrücken ist ebenso möglich wie das automatische Einfügen von schließenden Klammern beim Tippen oder das vertikale Selektieren (zu aktivieren unter EINSTELLUNGEN | EDITOR). Zudem können Sie auch bei KDevelop Lesezeichen in den Quelltexten setzen, zu denen Sie dann später springen können. Neben einem direkten Aufruf der Revisionskontrolle aus dem Editor ist auch eine Navigationshilfe zwischen Deklaration und Definition sowie ein Klassen-Wizard enthalten, der aus ein paar Angaben ein Klassengerüst erstellen kann.

Das Übersetzen ist denkbar einfach: ERSTELLEN | ERSTELLEN oder schlicht F8; allerdings müssen Sie bei den vom Wizard erzeugten Projekten unter Umständen noch ein paar Befehle im Makefile anpassen, bevor der Generierungsprozess fehlerfrei durchläuft. Das eigene Debugger-Frontend hat bereits fast alle Möglichkeiten, die man bei einer Debug-Sitzung braucht. Es werden sogar Einzelschrittverarbeitung sowie das Laden einer core-Datei unterstützt. Außerdem kann mit Hilfe von WERKZEUGE | KDBG ein externer Debugger namens kdbg (auch ein Frontend für gdb) gestartet werden, der wie die anderen Werkzeuge in einem Teil des KDevelop-Fensters läuft. Mit ihm können Sie so gut wie alle Funktionen des gdb nutzen.

Man sollte auch nicht vergessen, dass KDevelop die einzige der vorgestellten IDE ist, die unter Linux für die Entwicklung von grafischen Benutzeroberflächen vorgesehen ist. Alle anderen sind lediglich auf Server- oder Betriebssystem-Anwendungen ausgelegt, die nur Kommandozeilenein- und ausgaben haben. Für die GUI-Entwicklung bringt KDevelop neben dem KDE/Qt-Wizard und den Schnittstellen zu KIconEdit sowie KPaint noch einen eigenen Dialogeditor mit. So können Sie mit dessen Hilfe Ihre eigenen Dialog-Fenster zusammenstellen und so Ihrem Programm eine KDE-konforme Oberfläche geben. Leider kann ich in diesem Rahmen nicht näher auf die GUI-Programmierung eingehen; zusammen mit KDevelop bekommen Sie aber verschiedene sehr gute Tutorials, die Sie rasch die ersten Schritte in diese neue Welt gehen lassen. Versuchen Sie es doch einfach einmal!

Zusammenfassung

In diesem Abschnitt haben Sie drei weitere grafische Entwicklungsumgebungen unter Linux kennen gelernt. Der Source Navigator von RedHat bietet Ihnen die meisten der Funktionen, die Sie schon bei SNiFF+ gesehen hatten. Der CodeWarrior von Metrowerks bringt dagegen eine eigene Bedienphilosophie mit sich, was Ihnen den Umstieg auf Linux erleichtert, wenn Sie bereits auf einer anderen Plattform mit dieser IDE gearbeitet haben. KDevelop unterstützt Sie wiederum hervoragend, wenn Sie planen, eine Anwendung mit grafischer Benutzeroberfläche für das K-Desktop Environment (KDE) zu schreiben.

Diese Liste ist bei weitem noch nicht vollständig. Ich habe vielmehr versucht, Ihnen die derzeit aus meiner Sicht wichtigsten Entwicklungsumgebungen vorzustellen, damit Sie sich selbst entscheiden können, welche Ihnen am besten gefällt und Ihre Anforderungen am ehesten erfüllt. Denn letztlich sollen alle Ihnen ja nur dabei helfen, Ihre eigenen Programme zu entwickeln -- denn den Quelltext müssen Sie immer noch selbst schreiben.


next up previous contents index
Next: Bibliography Up: C++-Entwicklung mit Linux Previous: Werkzeuge für die Softwareentwicklung   Contents   Index
thomas@cpp-entwicklung.de

(C) T. Wieland, 2001. Alle Rechte vorbehalten.