Code::Blocks Manual
Version 1.0
Die Dokumentation für Listing 3 und Listing 4 sind offizielle Dokumentationen der CodeBlocks Wiki-Seite und nur in englischer Sprache verfügbar.
Die nachfolgende Abbildung zeigt den Aufbau der CodeBlocks Oberfläche.
Die Statusbar gibt einen Überblick der folgenden Einstellungen:
CodeBlocks bietet eine sehr flexible und umfassende Projektverwaltung. Der folgende Text geht nur auf einige Besonderheiten der Projektverwaltung ein.
In CodeBlocks werden Quellen und die Einstellungen für den Builtprozess in einer Projektdatei <name>.cbp gespeichert. Ein Projekt besteht typischerweise aus C/C++ Quellen und zugehörige Header Dateien. Ein neues Projekt legen Sie am einfachsten an, indem Sie das Menü ’File’ /’Project’ ausführen und einen Wizard auswählen. Anschließend können Sie im Management Fenster über das Kontextmenü ’Add files’ Dateien zum Projekt hinzufügen. In CodeBlocks werden die Projektdateien abhängig von ihrer Dateiendung in Kategorien verwalten. Die voreingestellen Kategorien sind für
Die Einstellungen für Typen und Kategorien von Dateien können über das Kontextmenü ’Project tree’ /’Edit file types & categories’ angepasst werden. Dabei können auch eigene Kategorien für Dateiendungen angelegt werden. Wenn Sie z.B. Linkerskripte mit der Endung *.ld unter der Kategorie Linkerscript anzeigen möchten, legen Sie einfach eine neue Kategorie an.
In CodeBlocks können zu Projekten sogenannte Notes hinterlegt werden. Diese sollten eine Kurzbeschreibung oder Hinweise für das jeweilige Projekt enthalten. Durch Anzeige dieser Information beim Öffnen des Projektes bekommen andere Bearbeiter einen schnellen Überblick. Die Anzeige von Notes kann bei den Properties eines Projektes im Reiter Notes aktiviert bzw. deaktiviert werden.
CodeBlocks wird mit einer Vielzahl von Projektvorlagen ausgeliefert, die beim Anlegen eines neuen Projektes angezeigt werden. Es ist aber auch möglich, eigene Vorlagen zu speichern und somit eigene Vorgaben für Compilerschalter, wie zu verwendete Optimierung, maschinenspezifische Schalter etc. in Vorlagen zusammenzufassen. Diese werden im Verzeichnis Dokumente und Einstellungen\<user>\Anwendungsdaten\codeblocks\UserTemplates abgelegt. Wenn die Vorlagen für alle Benutzer zugänglich sein sollen, müssen die Vorlagen in zugehöriges Verzeichnis der CodeBlocks Installation kopiert werden. Diese Vorlagen erscheinen dann beim nächsten Start von CodeBlocks unter ’New’ /’ Project’ /’User templates’ .
In Projekten ist es notwendig unterschiedliche Varianten eines Projektes vorzuhalten. Varianten werden als Build Target bezeichnet. Diese unterscheiden sich in der Regel durch unterschiedliche Compileroptionen, Debug-Information und Auswahl von Dateien. Ein Build Target kann auch in ein eigenständiges Projekt ausgelagert werden, dafür selektieren Sie in ’Project’ /’Properties’ den Reiter ’Build Targets’ die Variante und wählen Sie Schaltfläche ’Create project from target’ (siehe Abbildung 1.2).
Mit sogenannten Virtual Targets können Projekte in CodeBlocks weiter strukturiert werden. Eine häufige Projektstruktur besteht aus zwei Build Targets. Einem Target ’Debug’ mit Debuginformation und einem anderen Target ’Release’ ohne diese Information. Durch Hinzufügen von Virtual Targets unter ’Project’ /’Properties’ /’Build Targets’ können einzelne Build Targets zusammengefasst werden. So kann zum Beispiel ein Virtual Target ’All’ die Targets Debug und Release gleichzeitig erzeugen. Die Virtual Targets werden auch in der Symbolleiste des Compilers unter Build Targets angezeigt.
CodeBlocks ermöglicht es, weitere Arbeitschritte vor oder nach der Compilierung eines Projektes durchzuführen. Die Arbeitsschritte werden als Prebuilt bzw. Postbuilt Step bezeichnet. Typische Postbuilt Steps sind:
Beispiel
Erzeugung einer Disassembly aus einem Objekt unter Windows. Die Umlenkung in eine Datei erfordert den Aufruf der cmd mit der Option /c.
Ein weiteres Beispiel für ein Postbuilt Step kann die Archivierung eines Projektes sein. Hierzu erstellen Sie ein Build Target ’Archive’ und tragen im Postbuilt Step folgende Anweisung ein
Mit diesem Befehl wird das aktive Projekt und seine Quellen, Header und Objekte als Zip-Datei gepackt. Dabei werden über die Built-in Variablen $(PROJECT_NAME) und $(TODAY), der Projektname und das aktuelle Datum extrahiert (siehe Listing 3.2). Im Verzeichnis des Projektes liegt dann nach Ausführen des Targets ’Archive’ die gepackte Datei.
In dem Verzeichnis share/codeblocks/scripts finden Sie einige Beispiele für Skripte. Ein Skript kann über das Menü ’Settings’ /’Scripting’ hinzugefügt und in ein Menü eingetragen werden. Wenn Sie ein Skript z.B. make_dist über ein Menü ausführen, werden alle Dateien, die zum einem aktiven Projekt gehören in ein Archiv <project>.tar.gz komprimiert.
CodeBlocks bieten die Möglichkeit, Aktionen die vom Benutzer in Menüs ausgeführt werden, auch in Skripten zu verwenden. Mit dem Skript entsteht somit ein zusätzlicher Freiheitsgrad um die Generierung Ihres Projektes zu steuern.
In CodeBlocks können Sie mehrere Projekte geöffnet halten. Durch speichern der geöffneten Projekte über ’File’ /’Save workspace’ werden diese in einem Arbeitsbereich unter <name>.workspace zusammengefasst. Wenn Sie beim nächsten Start von CodeBlocks den Arbeitsbereich <name>.workspace öffnen erscheinen wieder alle Projekte.
Komplexe Softwaresysteme bestehen aus Komponenten, die in unterschiedlichen CodeBlocks Projekten verwaltet werden. Des weiteren existieren bei der Generierung von solchen Softwaresystemen oftmals Abhängigkeiten zwischen diesen Projekten.
Beispiel
Ein Projekt A enthält zentrale Funktionen, die auch anderen Projekten in Form einer Bibliothek zugänglich gemacht werden. Wenn nun diese Quellen eines Projektes geändert werden, muss die Bibliothek neu erzeugt werden. Damit die Konsistenz zwischen einem Projekt B, das die Funktionen verwendet und dem Projekt A, das die Funktionen implementiert, gewahrt bleibt, muss Projekt B von Projekt A abhängen. Die Information für die Abhängigkeit von Projekten wird im jeweiligen Workspace gespeichert, damit jedes Projekt weiterhin einzeln erzeugt werden kann. Durch die Verwendung von Abhängigkeiten kann auch die Reihenfolge bei der Generierung von Projekten gesteuert werden. Die Abhängigkeiten für Projekte werden über den Menüeintrag ’Project’ /’Properties’ und Auswahl der Schaltfläche ’Project’s dependencies’ gesetzt.
In der Projektansicht (Project View) im Fenter Management werden Assembler Dateien im Kategorie ASM Sources aufgeführt. Die Anzeige von Dateien und Kategorien kann vom Benutzer festgelegt werden (siehe 1.1). Durch einen Rechtsklick einer der gelisteten Assembler Dateien erhält man ein Kontextmenü. Darin öffnet der Befehl ’Properties’ ein neues Fenster. Klicken Sie darin auf den Reiter ’Build’ und aktivieren Sie die beiden Felder ’Compile file’ und ’Link file’. Wechseln Sie nun auf den Reiter ’Advanced’ und führen Sie folgende Schritte durch:
Dabei sind die CodeBlocks Variablen durch $ gekennzeichnet (siehe Listing 3.4). Diese werden automatisch ersetzt, so dass Sie lediglich die Assembleroption <asopt> durch Ihre Einstellungen ersetzen brauchen.
Durch vorgegebene Coding Rules im Unternehmen müssen Quelldateien einen einheitlichen Aufbau vorweisen. CodeBlocks bietet die Möglichkeit, beim Anlegen von neuen C/C++ Quellen und Header einen vorgegebenen Inhalt am Anfang einer Datei automatisiert einzufügen. Die vorgebene Inhalt wird als Default Code bezeichnet. Die Einstellung hierfür kann unter ’Stettings’ /’Editor’ Default Code vorgenommen werden. Eine neue Datei erzeugen Sie über das Menü ’File’ /’New’ /’File’ .
Beispiel
Durch Definition von Abkürzung in CodeBlocks kann einiges an Schreibarbeit und Zeit gespart werden. Hierzu werden in ’Settings’ /’Editor’ sogenannte Abbreviations unter dem Namen <name> angelegt, die über das Tastenkürzel Ctrl-J aufgerufen werden (siehe Abbildung 1.3).
Durch Einfügen von Variablen $(NAME) in den Abkürzungen ist auch eine Parametrisierung möglich.
Bei Aufruf der Abkürzung <name> im Quelltext und Ausführen von Ctrl-J, wird der Inhalt der Variablen abgefragt und eingefügt.
CodeBlocks Einstellungen werden als Anwendungsdaten im Verzeichnis codeblocks in einer Datei <user>.conf gespeichert. Diese Konfigurationsdatei enthält Informationen wie beispielsweise zuletzt geöffnete Projekte, Einstellungen für Editor, Anzeige von Symbolleisten etc. Standardmäßig ist die Personality ’default’ eingestellt, so dass die Konfiguration in der Datei default.conf abgelegt ist. Wenn CodeBlocks mit dem Parameter --personality=myuser in der Kommandozeile aufgerufen wird, werden die Einstellungen in der Datei myuser.conf gespeichert. Falls das Profil nicht bereits existiert, wird es automatisch angelegt. Durch diese Vorgehensweise können für unterschiedliche durchzuführende Arbeitsschritte auch zugehörige Profile gespeichert werden. Wenn Sie CodeBlocks mit dem zusätzlichen Parameter --personality=ask starten erscheint ein Auswahldialog für die verfügbaren Profile.
Die Einstellungen für CodeBlocks werden im Profil default.conf im Ordner codeblocks in Ihren Anwendungsdaten gespeichert. Bei Verwendung von personalities (siehe Listing 1.10.3 werden die Konfiguration in der Datei <personality>.conf abgelegt.
Mit dem Werkzeug cb_share_conf, aus dem CodeBlocks Installationsverzeichnis, können diese Einstellungen verwaltet und gesichert werden.
Falls Sie Standardeinstellung für mehrere Benutzer eines PCs vorgeben möchten, muss die Konfigurationsdatei default.conf im Ordner \Dokumente und Einstellungen\Default User\Anwendungsdaten\codeblocks abgelegt sein. Beim ersten Start von CodeBlocks werden die Voreinstellungen aus ’Default User’ in die Anwendungsdaten der aktuellen Benutzers kopiert.
Zur Erzeugung einer portablen Version von CodeBlocks auf einem USB-Stick gehen Sie wie folgt vor. Kopieren Sie die CodeBlocks Installation auf einen USB-Stick und legen Sie die Konfigurationsdatei default.conf in dieses Verzeichnis. Die Konfiguration wird als globale Einstellung verwendet. Bitte achten Sie darauf, dass die Datei schreibbar sein muss, damit Änderungen in der Konfiguration auch gespeichert werden können.
In CodeBlocks existieren unterschiedliche Möglichkeiten zum schnellen Navigieren zwischen Dateien und Funktionen. Eine typische Vorgehensweise ist das Setzen von Lesezeichen (Bookmarks). Durch Betätigen des Tastenkürzel (Ctrl-B) wird ein Lesezeichen in einer Quelldatei gesetzt bzw. gelöscht. Mit (Alt-PgUp) wird zum vorherigen Lesezeichen gesprungen und mit (Alt-PgDn) zum nächsten gewechselt.
In der Projektansicht können Sie durch Auswählen eines Projektes oder im gesamten Workspace über das Kontextmenü ’Find file’ in einem Dialog einen Dateinamen angeben. Dieser wird anschließend in der Projektansicht markiert und durch Eingabe mit Return im Editor geöffnet (siehe Abbildung 1.4).
Für das schnelle Navigieren zwischen Header/Quelle Dateien bietet CodeBlocks folgende Möglichkeiten
CodeBlocks bietet verschiedene Möglichkeiten für die Suche in einer Datei oder in Verzeichnissen. Mit dem ’Search’ /’Find’ (Ctrl-F) oder ’Find in Files’ (Ctrl-Shift-F) öffnet sich der Dialog für die Suche.
Eine weitere komfortable Funktion bietet das Tastenkürzel Alt-G und Ctrl-Alt-G. Der sich öffnende Dialog erlaubt die Auswahl von Dateien/Funktionen und springt anschließend an die Implementierung der Funktion (siehe Abbildung 1.6) bzw. öffnete die ausgewählte Datei. Als Eingabe werden auf Wildcards * oder ? etc. für eine inkrementelle Suche unterstützt.
Wenn Sie sich im Editor Fenster befinden, können Sie mit Ctrl-Tab zwischen den Reiter von geöffneten Dateien springen. Durch setzen der Einstellung ’Use Smart Tab-switching scheme’ in ’Settings’ /’Notebook appearance’ erhalten Sie nun über Ctrl-Tab ein zusätzliches Open Tabs Fenster im Editor (siehe Abbildung 1.7). Dabei wird die Liste in der Reihenfolge der geöffneten Dateien gezeigt. Sie können die Tastenkombination Ctrl-Tab auch im Management Fenster verwenden, um in zwischen den Reitern zu wechseln.
Eine häufige Arbeitsweise bei der Entwicklung von Software ist jedoch, dass man sich durch ein Satz von Funktion hangelt, die in unterschiedlichen Dateien implementiert sind. Durch das Plugin Browse Tracker zeigt mit dem Fenster ’Browsed Tabs’ eine Liste in der Reihenfolge wie Dateien selektiert wurden. Somit können Sie komfortabel zwischen den Aufrufen navigieren (siehe Listing 2.8).
In CodeBlocks aktivieren Sie die Anzeige von Zeilennummern in ’Settings’ /’General Settings’ im Feld ’Show line numbers’. Mit dem Tastenkürzel Ctrl-G oder über das Menü ’Search’ /’Goto line’ springen Sie an die gewünschte Zeile.
Für das Navigieren über Funktionen oder Variablen bietet das Management Fenster in CodeBlocks eine Baumansicht für Symbole von C/C++ Quellen. Dabei lässt sicht der Gültigkeitsbereich (Scope) der Ansicht auf die aktuelle Datei oder Projekt oder den gesamten Arbeitsbereich einstellen.
Für die Kategorien der Symbole existieren folgende Kategorien.
Strukturen und Klassen werden unterhalb von Preprocessor symbols angezeigt. Wenn eine Kategorie mit der Maus angewählt wird, erscheinen die gefundenen Symbole in dem unteren Teil des Fensters (siehe Abbildung 1.8). Ein Doppelklick auf das Symbol öffnet die Datei, wo das Symbol definiert bzw. die Funktion implementiert ist und springt an die zugehörige Zeile.
Die Entwicklungsumgebung CodeBlocks unterstützt das Einbinden von externen Hilfen über das Menü ’Settings’ /’Environment’ . Fügen Sie ein Manual Ihrer Wahl im chm Format in ’Help Files’ hinzu und wählen Sie die Einstellung ’this is the default help file’ (siehe Abbildung 1.9). Dabei steht im Eintrag $(keyword) als Platzhalter für einen Begriff der im Editor markiert wird. Nun können Sie in CodeBlocks in einer geöffneten Quelldatei eine Funktion mit der Maus durch Doppelklick markieren und anschließend die Hilfe mit F1 aufrufen und erhalten die zugehörige Dokumentation.
Wenn Sie mehrere Hilfedateien einbinden, können Sie im Editor einen Begriff markieren und anschließend über das Kontextmenü ’Locate in’ die Hilfedatei auswählen, in der CodeBlocks suchen soll.
In CodeBlocks werden auch die Hilfe mit man pages unterstützt. Hier fügen Sie einen neuen Eintrag ’man’ ein und geben den Pfad wie folgt an.
CodeBlocks bietet auch einen ’Embedded HTML Viewer’, hiermit können einfache HTML-Dateien in CodeBlocks angezeigt und für Suchen genutzt werden. Konfigurieren Sie einfach den Pfad der HTML-Datei, die durchsucht werden soll und aktivieren Sie die Option ’Open this file with embedded help viewer’ in dem Menü ’Settings’ /’Environment’ /’Help Files’ .
Die Einbindung von externen Tools ist in CodeBlocks unter dem Menüeintrag ’Tools’ /’Configure Tools’ /’Add’ vorgesehen. Für die Übergabeparameter der Tools kann auch auf Built-in Variables (see Listing 3.2) zugegriffen werden. Des weiteren existieren für das Starten von externen Anwendungen unterschiedliche Arten (Launching options). Je nach Option werden die extern gestarteten Anwendung beim Beenden von CodeBlocks gestoppt. Falls die Anwendungen auch beim Beenden von CodeBlocks geöffnet bleiben sollen, ist die Option ’Launch tool visible detached’ einzustellen.
In diesem Kapitel werden Ihnen einige nützliche Einstellungen in CodeBlocks vorgestellt.
CodeBlocks bietet die Möglichkeit geänderte Stellen eines Quellcodes im Vergleich zu einer Vorversion mit Hilfe von seitlich angebrachten Revisionsbalken automatisch sichtbar zu machen. Dabei werden Änderungen mit einem gelben Balken und gespeicherte Änderungen mit einem grünen Balken dargestellt (siehe Abbildung 1.11). Das Navigieren zwischen den einzelnen Änderungen ist über das Menü ’Search’ /’Goto next changed line’ oder ’Search’ /’Goto previous changed line’ möglich. Standardmäßig sind hierfür die Tastenkürzel Ctrl-F3 und Ctrl-Shift-F3 konfiguriert.
Diese Feature kann unter ’Settings’ /’Editor’ /’Margins and caret’ mit der Checkbox ’Use Changebar’ aktiviert bzw. deaktiviert werden.
Zwischen CodeBlocks und anderen Anwendungen können Daten dynamisch ausgetauscht werden. Diese Interprozess Kommuikation wird unter Windows auf DDE (Dynamic Data Exchange) und unter anderen Betriebssystemen auf eine TCP Kommunikation zwischen den Anwendungen abgebildet.
Über diese Schnittstelle können an CodeBlocks Kommandos mit der folgenden Syntax weitergegeben werden.
Als Kommandos stehen zur Verfügung:
Mit dem folgenden Kommando
wird der Parameter, hier die Datei mit absolutem Pfad, innerhalb einer CodeBlocks Instanz geöffnet oder bei Bedarf eine erste Instanz gestartet.
Das Kommando öffnet eine Datei mit spezifizierter Zeilennummer in einer CodeBlocks Instanz. Diese Zeilennummer wird mit :line angegeben.
Setzt den Fokus auf die CodeBlocks Instanz. Hier darf kein Parameter angegeben werden.
Die Konfiguration für ein Betriebssystem wird durch sogenannte Umgebungsvariablen festgelegt. Zum Beispiel enthält die Umgebungsvariablen PATH den Pfad auf einen installierten Compiler. Das Betriebssystem geht diese Umgebungsvariable von vorne nach hinten durch, d.h. die Einträge am Ende werden als letztes durchsucht. Wenn nun unterschiedliche Versionen eines Compilers oder anderer Anwendungen installiert sind, können nun folgende Situationen auftreten:
Es könnte zum Beispiel notwendig sein, dass für unterschiedliche Projekte unterschiedliche Versionen eines Compilers oder anderer Werkzeugen vorgeschrieben sind. Eine Möglichkeit ist die Umgebungsvariablen in der Systemsteuerung jeweils für ein Projekt zu ändern. Diese Vorgehensweise ist jedoch fehleranfällig und nicht flexibel. Für diese Anforderung bietet CodeBlocks eine elegante Lösung. Es lassen sich hier unterschiedliche Konfigurationen von Umgebungsvariablen erstellen, die nur intern in CodeBlocks verwendet werden. Zusätzlich kann zwischen diesen Konfiguration umgeschaltet werden. Die Abbildung 1.12 zeigt den Eingabedialog, den Sie über das Menü ’Settings’ /’Environment’ und Auswahl von ’Environment Varibales’ erhalten. Eine Konfiguration wird über die Schaltfläche ’Create’ erzeugt. Die Übernahme der hinzugefügten Umgebungsvariablen erfolgt durch Bestätigen des OK Knopfes. Das Aktivieren einer Konfiguration erfolgt über den Knopf Set Now.
Der Zugriff und der Gültigkeitkeitbereich auf die hier erstellten Umgebungsvariablen ist auf CodeBlocks begrenzt. Sie können diese Umgebungsvariablen wie auch andere CodeBlocks Variablen über $(NAME) expandieren.
Beispiel
Sie können die verwendete Umgebung in einem postbuild Step (siehe 1.6) in einer Datei <project>.env schreiben und zu Ihrem Projekt archivieren.
oder unter Linux
Abhängig von der Aufgabenstellung ist es sinnvoll unterschiedliche Konfigurationen oder Ansichten in CodeBlocks zu haben und diese zu speichern. Standardmäßig werden die Einstellungen wie z.B. Anzeige von Symbolleisten, Layout etc. in der Konfigurationsdatei default.conf gespeichert. Durch die Verwendung der Kommandozeilenoption --personality=ask beim Start von CodeBlocks kann zwischen verschiedenen Einstellungen umgeschaltet werden. Neben dieser globalen Einstellung besteht jedoch häufig auch der Wunsch während einer Session zwischen Ansichten für Fenster und Symbolleisten zu wechseln. Zwei typische Szenarien sind z.B. das Editieren von Dateien oder das Debuggen eines Projektes. Damit der Anwender nicht ständig mit dem Öffnen und Schließen von Fenstern, Symbolleisten etc. beschäftigt ist, bietet CodeBlocks einen Mechanismus um unterschiedliche Perspektiven zu speichern bzw. diese umzuschalten. Über das Menü ’View’ /’Perspectives’ /’Save current’ und Eingabe eines Namens <name> wird eine Perspektive gespeichert. Über ’Settings’ /’Editor’ /’Keyboard shortcuts’ /’View’ /’Perspectives’ /’<name>’ kann ein Tastenkürzel hierfür angegeben werden. Durch diese Vorgehensweise können Sie nun einfach zwischen den Ansichten über Ihre Tastenkürzel wechseln.
Wenn mehrere Projekte oder Dateien gleichzeitig geöffnet sind, so will der Benutzer häufig zwischen den Projekten und Dateien schnell wechseln können. CodeBlocks stellt hierfür eine Reihe an Shortcuts zur Verfügung.
Beim Buildprozess eines Projektes werden die Ausgaben des Compilers in Fenster Messages im Reiter Build Log ausgegeben. Wenn Sie an detaillierten Information interessiert sind, kann die Ausgabe erweitert werden. Dazu wählen Sie unter ’Settings’ /’Compiler and Debugger’ im Reiter ’Other Settings’.
Achten Sie darauf, dass beim Eintrag Selected Compiler der gewünschte Compiler eingestellt ist. Die Einstellung ’Full command line’ im Feld Compiler Logging gibt die vollständige Information im Build Log aus. Zusätzlich kann diese Ausgabe in eine HTML-Datei geloggt werden. Hierzu ist die Einstellung ’Save build log to HTML file when finished’ erforderlich. Des weiteren bietet CodeBlocks eine Fortschrittsanzeige des Buildprozesses im Fenster Build Log. Diese aktivieren Sie mit dem Einstellung ’Display build progress bar’.
CodeBlocks bietet einen sehr leistungsfähigen Editor. Eine Besonderheit ist, dass Sie innerhalb einer geöffneten Datei die Darstellung vergrößern und verkleinern können. Wenn Sie eine Maus mit einem Scrollrad haben, halten Sie einfach die Ctrl-Taste gedrückt und scrollen im Editor über das Rad nach vorne oder hinten.
Für das Editieren von Textdateien z.B. *.txt innerhalb CodeBlocks ist es nützlich den Eingabetext automatisch auf die Textbreite des Editorfensters in mehrere Zeilen umbrechen zu lassen. Diese Funktionalität wird ’Word wrap’ genannt und diese lässt sich im Menü ’Settings’ /’Editor’ /’Other Options’ und mit der Checkbox ’Word wrap’ aktivieren. Durch die Home/Pos 1 Taste springt der Cursor an den Anfang und mit End/Ende an das Ende der umgebrochenen Zeilen. Durch die Einstellung ’Settings’ /’Editor’ /’Other Options’ und dem Setzen von ’Home key always move to caret to first column’ wird erreicht, dass die Home/Pos 1 bzw. End/Ende Taste der Cursor an den Zeilenanfang bzw. an das Ende der aktuellen Zeile springt. Falls jedoch ein Sprung des Cursors an den Zeilenanfang des Abschnitts gewünscht ist, muss stattdessen die Tastenkombination ’Atl-Home/Pos 1’ gedrückt werden. Entsprechendes gilt für ’Alt-End/Ende’ .
CodeBlocks unterstützt im Editor einen sogenannten Block select mode. Hiermit können bei gedrückter ’ALT’ Taste ein Rechteck mit der linken Maustaste aufziehen und kopieren bzw. einfügen. Dies ist zum Beispiel nützlich, wenn nur einige Spalten eines Array markiert und kopiert werden sollen.
CodeBlocks unterstützt ein sogenanntes Folding für Quellen. Hiermit lassen sich zum Beispiel Funktionen zusammenklappen. Ein Folding Punkt erkennen Sie im Editor als Minussymbol im linken Seitenrand. Hier wird auch der Beginn und das Ende eines Folding Punktes durch eine vertikale Linie gekennzeichnet. Wenn Sie mit der linken Maustaste auf das Minussymbol klicken wir der entsprechende Abschnitt eingekappt bzw. ausgeklappt. Sie können über das Menu ’Edit’ /’Folding’ einstellen wie eingeklappt werden soll. Im Editor wird ein eingeklappte Codestelle durch eine durchgehende horizontale Linie dargestellt.
Neben dem Folding für Funktionen kann die Funktionalität auch für Präprozessor Direktiven eingestellt werden. Aktivieren Sie hierfür die Option ’Fold preprocessor commands’ im Menü ’Settings’ /’Editor’ unter dem Eintrag Folding.
Eine weitere Möglichkeit ist benutzerdefinierte Folding Punkte zu definieren, indem ein Kommentarzeichen durch eine geöffnete Klammer den Anfang und ein Kommentar mit schließender Klammer das Ende markiert.
CodeBlocks parst beim Öffnen eines Projektes die ’Search directories’ die für einen Compiler oder Projekt eingestellt wurden und die im Projekt befindlichen Quellen und Header. Des weiteren werden auch die Keywords der zugehörigen Lexerdateien geparst. Die aus dem Parsen gewonne Information über Symbole kann für die sogenannte Auto completion genutzt werden, wenn diese in den Einstellungen des Editors für CodeBlocks aktiviert ist. Die Auto completion können Sie im Editor über das Tastenkürzel Ctrl-Space ausführen. Im Menü ’Settings’ /’Editor’ /’Syntax highlighting’ können eigene keywords zum Lexer hinzugefügt werden.
Wenn eine Datei auf der Festplatte gelöscht wurde, jedoch in der Projektbeschreibung <project>.cbp noch enthalten ist, dann wir diese Datei als ’broken file’ mit einem unterbrochenem Symbol in der Project View von CodeBlocks angezeigt. Das Entfernen einer Datei sollte in der Projekt View mit dem Kontextmenü ’Remove file from project’ vorgenommen werden.
Bei größeren Projekten mit vielen Unterordnern kann die Suchen nach ’broken files’ sehr schwierig werden. CodeBlocks bietet jedoch mit dem Plugin ThreadSearch (siehe Listing 2.6) eine einfache Lösung. Wenn Sie in ThreadSearch einen Suchbegriff eingeben und als Option ’Project files’ oder ’Workspace files’ wählen, wird ThreadSearch alle Dateien eines Projektes durchsuchen; falls ein ’broken file’ im Projekt oder Workspace vorkommt, wird als Fehler diese Datei gemeldet.
In den Builtoption eines Projektes können Sie unter ’Linker Settings’ im Eintrag ’Link libraries’ über die Schaltfläche ’Add’ verwendete Bibliotheken hinzufügen. Dabei können Sie entweder den absoluten Pfad zur Bibliothek durchsuchen oder nur den Namen ohne den Prefix lib und die Dateiendung angeben.
Beispiel
Für eine Bibliothek <path>\libs\lib<name>.a geben Sie einfach <name> an. Der Linker mit den jeweiligen Suchpfaden für die Bibliotheken bindet diese dann korrekt ein.
Beim Compilierung werden aus Quellen name.c/cpp werden Objekte name.o erzeugt. Der Linker bindet die einzelnen Objekten zu einer Anwendung name.exe oder für den Embedded Bereiche name.elf. In einigen Fällen ist es wünschenswert die Reihenfolge für das Binden von Objekten vorzugeben. In CodeBlocks kann dies durch die Vergabe von sogenannten Prioritäten erzielt werden. Stellen Sie für eine Datei über das Kontextmenü ’Properties’ im Reiter Build die Priorität ein. Dabei führt eine geringe Priorität des Objekts dazu, dass es zu erst gebunden wird.
CodeBlocks bietet die Möglichkeit Projekte und Quelldateien automatisch zu speichern bzw. eine Sicherungskopie anzulegen. Diese Funktionalität wird im Menü ’Settings’ /’Environment’ /’Autosave’ eingestellt. Dabei sollte als ’Save to .save file’ als Methode für das Erstellen einer Sicherungskopie eingestellt werden.
In CodeBlocks können Sie zwischen verschiedenen Arten der Behandlung von Dateiendungen wählen. Die Einstellungen erhalten Sie über ’Settings’ /’Files extension handling’ . Sie können entweder die von Windows zugeordneten Anwendungen (open it with the associated application) für entsprechende Dateiendungen verwenden oder für jede Dateiendungen die Einstellungen so ändern, dass entweder ein benutzerdefiniertes Programm (launch an external program) gestartet wird oder die Datei in Editor von CodeBlocks geöffnet wird (open it inside Code::Blocks editor).
Die IDE CodeBlocks kann auch ohne grafische Oberfläche in der Kommandozeile ausgeführt werden. Dabei stehen unterschiedliche Schalter zur Verfügung um den Buildprozess eines Projektes zu steuern. Da CodeBlocks somit skriptfähig ist, kann die Erzeugung von Exectutables in eigene Arbeitsabläufe integriert werden.
Specifies the project *.cbp filename or workspace *.workspace filename. For instance, <filename> may be project.cbp. Place this argument at the end of the command line, just before the output redirection if there is any.
Open file in Code::Blocks and optionally jump to a specific line.
Shows a help message regarding the command line arguments.
Don’t perform any file association checks (Windows only).
Don’t start a DDE server (Windows only).
Don’t start an IPC server (Linux and Mac only).
Hides the splash screen while the application is loading.
Display the debug log of the application.
Sets the shared data directory prefix.
Sets the personality to use. You can use ask as the parameter to list all available personalities.
Clean and build the project or workspace.
Build the project or workspace.
Sets target for batch build. For example --target=’Release’.
Keeps the batch log window visible after the batch build is completed.
Shows a message after the batch build is completed.
Alle Plugins werden beim Start deaktiviert.
Placed in the very last position of the command line, this may be used to redirect standard output to log file. This is not a codeblock option as such, but just a standard DOS/*nix shell output redirection.
Auch wenn man eine IDE wie CodeBlocks überwiegend mit der Maus bedient, erweisen sich dennoch Tastenkombinationen immer wieder als hilfreich, um die Arbeit zu vereinfachen und zu beschleunigen. In nachstehender Tabelle sind einige verfügbare Tastenkombinationen zusammengefasst.
This is a list of shortcuts provided by the CodeBlocks editor component. These shortcuts cannot be rebound.
Artistic Style dient dem Einrücken, Formatieren und ’Verschönern’ für C, C++, C# Quellen. Es kann verwendet werden um unterschiedliche Coding Rules für CodeBlocks einzustellen.
Wenn Quellen eingerückt werden, tendieren Programmierer dazu sowohl Leerzeichen als auch Tabulatoren einzusetzen, um die gewünschte Einrückung zu erzielen. Darüberhinaus gibt es auch Editoren die standardmäßig Tabulatoren durch eine feste Anzahl von Leerzeichen ersetzen. Andere Editoren versuchen den Code durch Einfügen von White space lesbarer zu machen selbst wenn der Code Tabulatoren enthält.
Da die Anzeige der Leerzeichen für jeden Tabulator durch die Einstellungen im Editor bestimmt ist, wirft dies immer ein Problem auf, wenn Programmierer unterschiedliche Editoren verwenden. Selbst bei größter Sorgfalt für die Formatierung der Quelle kann das Editieren durch andere Programmieren mit unterschiedlichen Editoren oder Einstellungen schnell Problemen verursachen.
Um diesen Problem Rechnung zu tragen, wurde Artistic Style entwickelt - ein Filter, der automatisch Ihre C / C++ / C# einrückt und formatiert.
Das Plugin CodeSnippets ermöglicht es Textbausteine und Verknüpfungen auf Dateien in einer Baumansicht nach Kategorien zu strukturieren. Die Bausteine dienen dazu, häufig verwendete Dateien oder Konstrukte in Textbausteine abzulegen und zentral zu verwalten. Stellen Sie sich vor eine Reihe von häufig verwendeten Quelldateien sind im Dateisystem in unterschiedlichen Ordnern abgelegt. Im Fenster CodeSnippets können Sie nun Kategorien und darunter Verknüpfungen auf die gewünschten Dateien erstellen. Damit können Sie den Zugriff auf die Dateien unabhängig von der Ablage im Dateisystem verwalten und ohne das Dateisystem zu durchsuchen schnell zwischen diesen Dateien navigieren.
Die Liste der Textbausteine und Verknüpfungen können im CodeSnippets Fenster mit der rechten Maustaste über das Kontextmenü ’Save Index’ gespeichert werden. Die dabei erzeugte Datei codesnippets.xml befindet sich anschließend in Ihren Dokumente und Einstellungen\Anwendungsdaten im Ordner codeblocks. Unter Linux wird diese Information im HOME-Verzeichnis im Ordner .codeblocks abgelegt. Die Konfigurationsdateien von CodeBlocks werden beim nächsten Start geladen. Falls Sie den Inhalt von CodeSnippets an einen anderen Ort speichern möchten, selektieren Sie den Eintrag ’Save Index As’. Zum Laden dieser Datei wählen Sie beim nächsten Start von CodeBlocks’Load Index File’ oder stellen das Verzeichnis in dem Kontextmenü ’Settings’ unter ’Snippet Folder’ ein. Diese Einstellungen werden in der zugehörigen Datei codesnippets.ini in den Anwendungsdaten hinterlegt.
Das Einfügen einer Kategorie geschieht über das Menü ’Add SubCategory’. In einer Kategorie können Snippets (Textbausteine) oder File Links (Verknüpfungen) liegen. Ein Textbaustein wird mit dem Kontextmenü über ’Add Snippet’ angelegt. Indem Sie einen Text im CodeBlocks Editor markieren und anschließend bei gedrückter linker Maustaste per Drag and Drop auf den Textbaustein ziehen, wird der Inhalt in den Textbaustein eingefügt. Wenn Sie einen selektierten Text auf eine Kategorie ziehen wird in diesem Ordner automatisch ein Textbaustein mit dem Namen ’New snippet’ erzeugt und es öffnet sich der Properties Dialog. Durch einen Doppelklick auf den neu eingefügten Eintrag oder durch Auswahl von ’Edit Text’ öffnet sich ein eigenständiger Editor zum Bearbeiten des Inhaltes.
Die Ausgabe eines Textbausteines in CodeBlocks erfolgt über das Kontextmenü ’Apply’ oder durch Drag und Drop in den Editor. Die Inhalte eines Snippets können auch in andere Anwendungen gezogen werden. Im CodeSnippets Browser können Sie auch per Drag and Drop einen Eintrag in eine andere Kategorie kopieren.
Textbausteine sind darüberhinaus auch über Variablen <name>, die über $(name) zugegriffen werden, parametrisierbar (siehe Abbildung 2.2). Die Abfrage für die Werte der Variablen erfolgt über ein Eingabefeld, wenn der Textbaustein mit dem Kontextmenü ’Apply’ aufgerufen wird.
Neben den Textbausteinen können auch Verknüpfungen auf Dateien angelegt werden. Wenn Sie zuvor einen Textbaustein angelegt haben und anschließend das Kontextmenü ’Properties’ auswählen, selektieren Sie mit der Schaltfläche ’Link target’ das Ziel der Verknüpfung. Eine Verknüpfung kann auch über das Kontextmenü ’Convert to FileLink’ erzeugt werden. Dieser Schritt wandelt den Textbaustein automatisch in eine Verknüpfung auf eine Datei um. In CodeSnippets werden Textbausteine mit einem T-Symbol und Verknüpfungen auf eine Datei mit einen F-Symbol und Urls mit einem U-Symbol gekennzeichnet. Falls Sie die in Codesnippets markierte Datei (Verknüpfung) öffnen möchten selektieren Sie im Kontextmenü ’Open File’ oder halten Sie die ’Alt’ Taste gedrückt und machen ein Doppelklick auf die Datei.
Falls Sie diese Einstellung vorgenommen haben, dann wird wenn Sie z.B. einen Verknüpfung auf eine pdf-Datei aus der Codesnippets Ansicht öffnen automatisch ein pdf-Viewer gestartet. Dieses Vorgehen ermöglicht dem Benutzer Dateien, die über das Netzwerk verteilt liegen, wie z.B. CAD Daten, Schaltpläne, Dokumentation etc. als Verknüpfung einfach über die gewohnten Anwendungen zuzugreifen. Der Inhalt der Codesnippets wird in der Datei codesnippets.xml und die Konfiguration in der Datei codesnippets.ini in Ihren Anwendungsdaten gespeichert. In dieser ini Datei wird z.B. der Ablageort der Datei codesnippets.xml hinterlegt.
CodeBlocks unterstützt die Verwendung von unterschiedlichen Profilen. Diese werden als personalities bezeichnet. Wenn Sie CodeBlocks mit der Kommandozeilen Option --personality=<profile> starten, wird entweder ein neues angelegt oder ein existierendes Profil verwendet. Die Einstellungen werden dann statt in default.conf in der Datei <personality>.conf in den Anwendungsdaten gespeichert. Das Plugin Codesnippets speichert seine Einstellungen dann in der Datei <personality>.codesnippets.ini. Wenn nun Sie in den Settings von Codesnippets über ’Load Index File’ einen neuen Inhalt <name.xml> laden, wird dies in der zugehörigen ini Datei hinterlegt. Der Vorteil von dieser Vorgehensweise ist, dass Sie zu unterschiedlichen Profilen auch unterschiedliche Konfigurationen für Textbausteine und Verknüpfungen verwalten können.
Für das Navigieren zwischen den Kategorien und Snippets bietet das Plugin eine zusätzliche Suchfunktion. Hierbei lässt sich auch der Gültigkeitsbereich (Scope) für die Suche auf Snippets, Categories oder Snippets and Categories einstellen. Durch Eingabe des gewünschten Suchbegriffes wird automatisch der zugehörige Eintrag in der Ansicht ausgewählt. Die Abbildung 2.3 zeigt eine typische Ansicht im CodeSnippets Fenster.
Für eine effiziente Suche in geöffneten Dateien bietet CodeBlocks die sogenannte Incremental Search Methode. Über das Menü ’Search’ /’Incremental Search’ oder das Tastenkürzel Ctrl-I wird diese Suchmethode für eine geöffnete Datei eingeleitet. Dabei wird dann automatisch der Focus auf die Suchmaske der zugehörigen Werkzeugleiste gesetzt. Wenn Sie mit der Eingabe eines Begriffes beginnen, wird abhängig von dem Vorkommen der Hintergrund der Suchmaske hinterlegt. Sobald ein Treffer im aktiven Editor gefunden wird, erscheint diese Stelle farblich markiert. Standardmäßig wird der aktuelle Treffer grün hervorgehoben. Die Einstellungen hierfür können im Menü ’Settings’ /’ Editor’ /’ Incremental Search’ geändert werden (siehe Abbildung 2.4). Durch Betätigen der Return Taste wird zum nächsten Vorkommen des Suchbegriffes gesprungen.
Wird der Suchbegriff in der aktiven Datei jedoch nicht gefunden, wird dies durch rotes Hinterlegen der Suchmaske signalisiert.
Die Icons in der Werkzeugleiste von Incremental Search sind wie folgt zu verstehen:
Für komplexe Software-Projekte, an denen unterschiedliche Benutzer arbeiten, hat man häufig die Anforderung, dass zu erledigende Arbeiten von unterschiedlichen Usern umzusetzen sind. Für dieses Problem bietet CodeBlocks eine Todo List. Diese Liste, zu öffnen unter ’View’ /’To-Do list’ , enthält die zu erledigenden Aufgaben mit Prioritäten, Typ und zuständige User. Dabei kann die Ansicht nach zu erledigenden Aufgaben nach Benutzer und/oder Quelldatei gefiltert werden. Eine Sortierung nach Spalten erhält der Benutzer durch Anklicken der jeweiligen Spaltenüberschrift.
Ein Todo lässt sich bei geöffneten Quellen in CodeBlocks über die rechte Maustaste ’Add To-Do item’ hinzufügen. Im Quellcode wird ein entsprechender Kommentar an der ausgewählten Quellzeile eingefügt.
Beim Hinzufügen eines To-Do erhalten Sie einen Eingabedialog mit folgenden Einstellungen (siehe Abbildung 2.6).
Oft ergibt sich die Notwendigkeit, den Quelltext in andere Anwendungen oder in Emails zu übernehmen. Beim schlichten Kopieren des Textes geht jedoch die Formatierung verloren, was den Text sehr unübersichtlich macht. Die Export Funktion in CodeBlocks schafft hier Abhilfe. Über ’File’ /’Export’ kann ein gewünschtes Dateiformat für die Exportdatei ausgewählt werden. Danach übernimmt das Programm den Dateinamen und das Zielverzeichnis der geöffneten Quelldatei und schlägt diesen als Name zum speichern vor. Die jeweilige Dateiendung wird durch das Exportformat bestimmt. Es stehen folgende Formate zur Verfügung.
Über das Menu ’Search’ /’Thread Search’ lässt sich das entsprechende Plugin als Tab in der Messages Console ein- und ausblenden. In CodeBlocks kann mit diesem Plugin eine Vorschau für das Auftreten einer Zeichenkette in einer Datei, Workspace oder Verzeichnis angezeigt werden. Dabei wird die Liste der Suchergebnisse in der rechten Seite der ThreadSearch Console angezeigt. Durch Anklicken eines Eintrages in der Liste wird auf der linken Seite eine Vorschau angezeigt. Durch einen Doppelklick in der Liste wird die ausgewählte Datei im CodeBlocks Editor geöffnet.
ThreadSearch plugin bietet folgende Funktionalität
Nach dem das Plugin installiert wurde gibt es vier Arten die Suche zu starten.
Der Knopf ’Options’ öffnet den Dialog für die Konfiguration des ThreadSearch plugin (see Abbildung 2.8):
Sie können Filter für die Suche von Dateien konfigurieren.
Bei einer Suche nach mehreren Begriffen wird die Liste schnell unübersichtlich, deshalb bietet diese Einstellung die Möglichkeit vorangegangene Suchergebnisse beim Start einer Suche zu löschen.
Für das Verwalten des ThreadSearch Fenster stehen zwei Alternativen zur Auswahl. Mit der Einstellung ’Message Notebook’ wird das ThreadSearch Fenster in der Message Konsole angedockt. Mit der Einstellung ’Layout’ können Sie das Fenster aus der Message Konsole lösen und als freies Fenster anordnen.
Für die Ansicht der Suchergebnisse existieren zwei Ansichten. Mit der Einstellung ’List’ werden alle Einträge untereinander angezeigt. Der andere Mode ’Tree’ zeigt die Suchergebnisse in einer Baumansicht an. Dabei werden Suchergebnisse aus einer Datei in einem Knoten zusammengefasst.
Der Benutzer kann eine horizontale oder vertikale Teilung der Fenster für die Vorschau und die Ausgabe von Suchergebnissen angeben.
Die Ansicht für die Suchergebnisse lässt sich sortieren nach Pfad oder Dateiname.
Der File Explorer Abbildung 2.9 ist im FileManager Plugin enthalten. In Abbildung 2.9 ist der Aufbau des File Explorers dargestellt. Der File Explorer erscheint als Tab ’Files’ im Management Fenster.
Das oberste Eingabefeld dient zur Angabe des Pfades. Die History der letzten Einträge erhalten Sie durch Mausklick auf die Schaltfläche neben dem Eingabefeld. Dadurch öffnet sich das Listenfeld, in dem der entsprechende Eintrag ausgewählt werden kann. Die Pfeil-nach-oben-Schaltfläche rechts daneben schiebt die Anzeige der Verzeichnisstruktur um eins nach oben.
Im Feld ’Wildcard’ können Sie Filter für die Anzeige von Dateien angeben. Mit einer leeren Eingabe oder * werden alle Dateien angezeigt. Ein Eintrag *.c;*.h zeigt z.B. nur C-Quellen und Headerdateien an. Durch Öffnen des Listenfeldes kann wiederum eine History der letzten Einträge zur Auswahl angezeigt werden.
Durch Mausklick mit gedrückter Shift-Taste kann ein Block von Dateien und Verzeichnissen ausgewählt werden, durch Mausklick mit gedrückter Ctrl-Taste können mehrere einzelne Dateien und Verzeichnisse ausgewählt werden.
Für die Auswahl eines oder mehrerer Verzeichnisse im File Explorer stehen Ihnen über das Kontextmenü folgende Operationen zur Verfügung:
Für die Auswahl von Dateien und Verzeichnissen stehen im Kontextmenü folgende gemeinsamen Befehle zur Verfügung.
Folgende Einträge sind nur für die Auswahl ein oder mehrerer Dateien gültig.
Über den Menübefehl ’Settings’ /’Environment’ /’PowerShell’ können benutzerdefinierte Funktionen erstellt werden. In der Eingabemaske des PowerShell wird mit der Schaltfläche ’New’ eine neue Funktion angelegt, die frei benannt werden kann. Im Feld ShellCommand Executable wird das auszuführende Programm angegeben, im unteren Feld können dem auszuführenden Programm zusätzliche Parameter übergeben werden. Durch Auswahl der Funktion im Kontextmenü oder PowerShell-Menü wird die eingetragene Aktion für die markierten Dateien oder Verzeichnisse ausgeführt. Die Ausgabe wird dabei auf ein eigenes Shell-Window umgelenkt.
Als Beispiel wird für den Eintrag mit dem Namen ’SVN’ ein zugehöriger Menüeintrag in ’PowerShell’ /’SVN’ und im Kontextmenü des File-Explorers hinzugefügt. Hierbei bedeutet $file die Datei, welche im FileExplorer markiert ist, und $mpath die markierten Dateien oder Verzeichnisse.
Dieser sowie jeder weitere Befehl erzeugt ein Untermenü, in diesem Fall ’Extensions’ /’SVN’ /’Add’ . Das Kontextmenü wird entsprechend erweitert. Der Aufruf des Kontextmenüs führt das SVN-Kommando add für die ausgewählte(n) Datei(en)/Verzeichnis(se) aus.
TortoiseSVN ist ein weit verbreitetes SVN Programm, das im Explorer als context menu integriert ist. Das Programm TortoiseProc.exe von TortoiseSVN kann auch in the Kommandozeile gestartet werden und zeigt einen Dialog an, der zur Eingabe durch den Benutzer dient. Somit können die Befehle, die im Kontextmenü im Explorer zugänglich sind auch in der Kommandozeile ausgeführt werden. Dies ermöglicht diese Funktionalität sehr einfach als Shell extension in CodeBlocks einzubauen. Zum Beispiel wird die folgende Eingabe
eine im File Explorer von CodeBlocks ausgewählte Datei gegen die SVN base Version verglichen. Siehe hierzu Abbildung 2.10 wie dieses Kommando als Shell extension verfügbar wird.
Beispiel
Sie können den File-Explorer auch verwendet um Unterschiede zwischen verschiedenen Dateien oder Verzeichnisse anzeigen zu lassen. Dabei gehen Sie wie folgt vor.
In diesem Aufruf wird über die Variable $mpaths die im File-Explorer selektierten Dateien oder Verzeichnisse zugegriffen. Somit können Sie einfach ausgewählte Dateien oder Verzeichnisse gegeneineander vergleichen.
Als Übergabeparameter eines Befehl einer PowerShell unterstützt auch den Zugriff der in CodeBlocks verfügbaren Variablen (siehe Listing 3.2).
Aufzurufendes Programm.
Name der Datei ohne Endung.
Dateiendung der ausgewählten Datei.
Dateiname mit Endung.
Dateiname ohne Pfadangabe.
Ordnername mit Pfadangabe.
Ordnername ohne Pfadanabe.
Absoluter Pfad.
Relativer Pfad einer Datei oder Verzeichnis.
Liste der ausgewählten Dateien oder Ordner.
Zeichenkette die durch eine Eingabeaufforderung eingegeben wird.
Übergeordnetes Verzeichnis (../)
Browse Tracker ist ein Plugin um zwischen kürzlich geöffneten Dateien in CodeBlocks zu navigieren. Dabei wird die Liste der kürzlich geöffneten Dateien in einer History gespeichert. Im Menü ’View’ /’Browse Tracker’ /’Clear All’ können Sie die History löschen.
Das Fenster ’Browsed Tabs’ zum Navigieren in dieser Listen erhalten Sie über das Menü ’View’ /’Browse Tracker’ mit dem Eintrag ’Backward Ed/Forward Ed’ oder über das Tastenkürzel Alt-Left/Alt-Right. Das Browse Tracker Menü ist auch über die Rechte Maustaste als Kontextmenü zugänglich. Die Marker werden in der Layout-Datei layout file <projectName>.bmarks gespeichert.
Eine häufige Arbeitsweise bei der Entwicklung von Software ist, dass man sich durch ein Satz von Funktion hangelt, die in unterschiedlichen Dateien implementiert sind. Durch das Plugin BrowseTracks können Sie somit komfortabel zwischen den Aufrufen in unterschiedlichen Dateien navigieren.
Das Plugin erlaubt auch Browse Marker in jeder Datei innerhalb des CodeBlocks Editor zu setzen. Die Cursor Position wird für jede Datei gespeichert. Das Setzen eines Markers innerhalb einer Datei ist wahlweise über das Menü ’View’ /’ Browse Tracker’ /’ Set BrowseMarks’ oder durch einen Klick mit der linken Maustaste bei gehaltener Ctrl Taste möglich. Der Marker ist durch † im linken Seitenrand gekennzeichnet. Über das Menü ’View’ /’Browse Tracker’ /’Prev Mark/Next Mark’ oder das Tastenkürzel Alt-up/Alt-down kann zwischen den Marker innerhalb einer Datei gesprungen werden. Dabei werden die Marker beim Navigieren in der Reihenfolge angesprungen wie diese gesetzt wurden. Falls Sie die Marker innerhalb einer Datei nach Zeilennummern sortiert durchlaufen möchten, wählen Sie einfach das Menü ’View’ /’Browse Tracker’ /’Sort BrowseMark’ .
Mit dem ’Clear BrowseMark’ wird ein Marker in der ausgewählten Zeile gelöscht. Falls ein Marker für ein Zeile gesetzt ist, kann bei gehaltener linker Maustaste (1/4 Sekunde) und betätigen der Ctrl Taste der Marker für diese Zeile gelöscht werden. Mit dem Aufruf ’Clear All BrowseMarks’ oder mit Ctrl-left Klick werden alle Marker innerhalb einer Datei zurückgesetzt.
Die Einstellungen für das Plugin können im Menü ’Settings’ /’Editor’ /’Browse Tracker’ verändert werden.
Die Konfiguration für das Plugin wird in den Anwendungsdaten in der Datei default.conf gepseichert. Bei der Verwenundung einer Personality wird die Konfiguration aus der Datei <personality>.conf gelesen.
Eine Unterstützung für die SVN Versionskontrolle bietet das CodeBlocks Plugin TortoiseSVN. Im Menü ’TortoiseSVN’ /’Plugin settings’ lässt sich im Reiter ’Integration’ einstellen, wo die benutzerdefinierbaren SVN-Befehlen zur Verfügung stehen sollen.
In den Plugin Settings lässt sich zusätzlich im Integration Dialog ’Edit main menu’ beziehungsweise ’Edit popup menu’ konfigurieren welche SVN Kommandos im Menü bzw. Kontextmenü ausgeführt werden können.
Wenn Sie Bibliotheken in einer Anwendungen verwenden, muss Ihr Projekt so eingestellt werden, dass es nach diesen Bibliotheken sucht und diese anschließend benutzen kann. Dieser Vorgang kann zeitaufwändig und nervend sein, da jede Bibliothek unter Umständen durch unterschiedliche Arten von Option eingebunden werden muss. Des weiteren hängen die Einstellungen vom Host-Betriebssystem ab, was zu Inkompatibilitäten im Projekt für die Verwendung unter Unix und Windows führt.
LibFinder stellt folgende Kernfunktionalitäten zur Verfügung:
Die Suche nach Bibliotheken ist über das Menü ’Plugins’ /’Library finder’ erreichbar. Der Sinn besteht in der Suche nach Bibliotheken, die bereits auf Ihrem System installiert sind. Das Ergebnis der Suche wird in der Libfinder Datenbank gespeichert. Diese Ergebnisse werden nicht in den CodeBlocks Projektdateien gespeichert. Die Suche startet mit dem Aufruf des Dialogs für die Angabe von Suchpfaden. LibFinder scannt diese Verzeichnisse rekursiv. Falls Sie nicht ganz sicher sind, wo sich die Bibliotheken befinden, ist auch die Angabe eines allgemeinen Pfades möglich. Sie können auch ganze Laufwerke angeben — in diesem Fall wird die Suche länger dauern aber voraussichtlich werden dann alle Bibliotheken gefunden (siehe Abbildung 2.11).
Wenn LibFinder nach Bibliotheken sucht, verwendet es spezielle Regeln um das Vorhandsein von Bibliotheken zu erkennen. Jeder Satz an Regeln ist im einer xml Datei abgelegt. Derzeit unterstützt LibFinder die Suche von wxWidgets 2.6/2.8, CodeBlocks SDK and GLFW — die Liste wird zukünftig erweitert werden.
Nach der Suche, zeigt Libfinder die Suchergebnisse an (siehe Abbildung 2.12).
In der Liste wählen Sie dann die Bibliotheken aus, die in der Libfinder Datenbank gespeichert werden sollen. Beachten Sie das jede Bibliothek mehrere gültige Konfigurationen haben kann und die Einstellungen aus vorhergehenden Suchen für die Erzeugung eines Projektes dominieren.
Mit den nachfolgenden Einstellungen lässt sich konfigurieren, wie mit den Ergebnissen aus vorhergehenden Suchen umgegangen wird.
Eine weitere Alternative in diesem Dialog ist die Einstellung ’Set up Global Variables’ . Wenn diese Option ausgewählt ist, versucht LibFinder automatisch die globalen Variablen zu konfigurieren und den Umgang mit den Bibliotheken zu erleichtern.
Wenn Sie pkg-config auf Ihrem System installiert haben (ist meist auf Linux Systemen installiert), wird LibFinder auch die Bibliotheken aus diesem Tool verwenden. Es ist keine weitere Suche erforderlich, da diese beim Start von CodeBlocks automatisch geladen werden.
LibFinder fügt in Project Properties einen weiteren Reiter ’Libraries’ ein — diese Reiter zeigt die Bibliotheken an, die im Projekt verwendet werden und LibFinder bekannt sind. Um Bibliotheken in ein Projekt einzufügen, wählen Sie einfach einen Eintrag im rechten Ausschnitt und Klicken Sie den < Knopf. Das Entfernen einer Bibliothek aus einem Projekt geschieht durch Auswahl eines Eintrages im linken Ausschnitt und einen Klick auf den > Knopf (siehe Abbildung 2.13).
Die Anzeige von Bibliotheken, die LibFinder bekannt sind, kann gefiltert werden. Die Checkbox ’Show as Tree’ erlaubt das Umschalten zwischen kategorisiert und nicht kategorisierter Ansicht.
Wenn Sie Bibliotheken, die nicht in der LibFinder Datenbank verfügbar sind, einfügen wollen, wählen Sie den Eintrag ’Unknown Library’ . Sie sollte für die Angabe der Bibliothek das übliche Kürzel verwenden (entspricht normalerweise dem globalen Variablennamen) oder den Name der Bibliothek in pkg-config. Eine Liste von empfohlen Shortcodes finden Sie auf Global Variables. Die Verwendung dieser Option ist nur dann ratsam, wenn ein Projekt auf unterschiedlichen Systemen erzeugt werden soll, wo die erforderlichen Bibliotheken existieren und durch LibFinder ermittelt werden können. Der Zugriff auf eine globale Variable innerhalb von CodeBlocks sieht wie folgt aus:
Die Auswahl der Option ’Don’t setup automatically’ wird LibFinder anweisen die Bibliotheken nicht automatisch beim Kompilieren des Projektes einzubinden. In einem solchen Fall kann LibFinder aus einem Build Script ausgeführt werden. Ein Beispiel für ein solches Skript wird durch Auswahl des Menüs ’Add manual build script’ erzeugt und dem Projekt hinzugefügt.
Wizards erzeugen Projekte, die nicht LibFinder nutzen. Die Verwendung des Plugins erfordert, das der Benutzer die Einstellung in den Build options im Reiter ’Libraries’ anpasst. Die Vorgehensweise sieht so aus, dass alle Bibliothek spezifische Einstellungen entfernt werden müssen und die benötigten Bibliotheken im Reiter ’Libraries’ eingefügt werden.
Diese Art von Projeken werden somit unabhängig von dem verwendeten Betriebssytem. Solange nur Bibliotheken, die in der LibFinder Datenbank definiert wurden, verwendet werden, werden die Build Optionen eines Projektes automatisch aktualisiert, so dass die Einstellung auch für die plattformabhängigen Einstellungen von Bibliotheken funktionieren.
Ein Plugin zur Versionierung von Anwendungen, indem die Versions- und Buildnummer einer Anwendung jedesmal hochgezählt wird, wenn eine Änderung stattgefunden hat. Diese Information wird über einfach benutzbare Variablendeklarationen in der Datei version.h abgelegt. Des weiteren sind möglich: Übergaben im SVN Stil, ein Versionsschema Editor, ein Change Log Generator und ein Log Generator und vieles mehr †
Die Idee dieses Plugins entstand bei Entwicklung von Software, die sich im frühen pre-alpha Status befand und eine Art von Versionsinformation benötigte. Beschäftigt durch die Erstellung von Code, blieb keine Zeit um die Versionsnummer zu pflegen, deshlab wurde ein Plugin entwickelt, dass diese Arbeit erledigt und nur minimaler Bedienereingriff erfordert.
Hier finden Sie eine Liste von Features, die vom Plugin abgedeckt werden.
Wählen Sie einfach das Menü ’Project’ /’Autoversioning’ . Das Pop Up Fenster wie auf ?? erscheint.
Wenn Sie den Dialog mit yes bestätigen, dann wird der Konfigurationsdialog von Autoversioning angezeigt.
Nachdem Sie Ihr Projekt für Autoversioning konfiguriert haben, werden die Einstellungen aus dem Eingabedialog im Projekt gespeichert und eine Datei version.h wird angelegt. Ab diesem Zeitpunkt wird bei jedem Aufruf des Menüs ’Project’ /’Autoversioning’ der Konfigurationsdialog aufgerufen, um die Einstellung für Projektversion vorzunehmen, es sei denn Sie speichern die Änderungen des Plugins in Projektdatei.
Hier können Sie einfach die zugehörigen Version Values eintragen oder Auswählen ob Auto Versioning diese für Sie hochzählt (siehe Abbildung 2.15).
Einige Felder sind auf vordefiniert Werte voreingestellt (siehe Abbildung 2.16).
Hier stellen Sie ein, wie das Plugin die version values hochzählt (siehe Abbildung 2.17).
Hier können Sie einige Einstellungen für Auto Versioning vornehmen (siehe Abbildung 2.18).
Durch diese Einstellung wird die Eingabe für jegliche Änderung an einem Projekt in die Datei ChangesLog.txt generiert (siehe Abbildung 2.19).
Für die Verwendung der Variablen, die durch das Plugin erzeugt wurden, müssen Sie die Datei #include <version.h> in den Quellen einfügen. Ein Beispiel für eine Quelle könnte wie folgt aussehen:
Die erzeugte Headerdatei könnte beispielsweise im C++ Mode wie folgt aussehen:
Bei der Einstellung der Sprache C ergibt sich folgende Ausgabe ohne Namespaces:
Dieser Dialog ist über das Menü ’Project’ /’Changes Log’ erreichbar. Diese Dialog erscheint auch wenn die Einstellung ’Show changes editor’ für das Inkrementierung der Version (Changes Log) besteht. Im Dialog werden die Liste von Änderungen nach Modifikation der Quellen eines Projektes eingegeben (siehe Abbildung 2.20).
Hier ein Beispiel für eine Datei ChangesLog.txt, die durch Auto Versioning erzeugt wurde.
Anhand der Angaben in der Konfigurationsmaske ermittelt dieses einfache Plugin die Anteile von Code, Kommentaren und Leerzeilen für ein Projekt. Die Auswertung wird über das Menü ’Plugins’ /’Code statistics’ durchgeführt.
Dieses Plugin ermöglicht es, einen Begriff im Editor zu markieren und über das Kontextmenü ’Search at Koders’ in der Datenbank von [?] zu suchen. Dabei bietet der Eingabedialog zusätzlich die Möglichkeit, die Suche nach Programmiersprachen und Lizenzen zu filtern.
Durch diese Datenbanksuche finden Sie schnell Quellcode der aus anderen weltweiten Projekten von Universitäten, Consortiums und Organisationen wie Apache, Mozilla, Novell Forge, SourceForge und vielen mehr stammt und wiederverwendet werden kann, ohne dass jedes Mal das Rad neu erfunden werden muss. Bitte beachten Sie die jeweilige Lizenz des Quellcodes.
Eine einfache grafische Schnittstelle für das Profiler Programm GNU GProf.
Diese Plugin ermöglicht die Suche von Symbolen in Objekten und Bibliotheken. Dabei werden die Optionen und der Pfad für das Kommandozeilen Programm nm über den Reiter Options konfiguriert.
Mit der Schaltfläche ’Search’ wird die Suche gestartet und die Ergebnisse des Programms NM werden in einem eigenen Fenster SymTabs Result angezeigt. Der Name des Objekts bzw. Bibliothek, die das Symbol enthalten ist unter dem Titel NM’s Output gelistet.
CodeBlocks differentiates between several types of variables. These types serve the purpose of configuring the environment for creating a program, and at the same of improving the maintainability and portability. Access to the CodeBlocks variables is achieved via $<name>.
CodeBlocks treats the following functionally identical character sequences inside pre-build, post-build, or build steps as variables:
Variable names must consist of alphanumeric characters and are not case-sensitive. Variables starting with a single hash sign (#) are interpreted as global user variables (see Listing 3.7 for details). The names listed below are interpreted as built-in types.
Variables which are neither global user variables nor built-in types, will be replaced with a value provided in the project file, or with an environment variable if the latter should fail.
The variables listed here are built-in variables of CodeBlocks. They cannot be used within source files.
The filename of the current workspace project (.workspace).
The name of the workspace that is displayed in tab Projects of the Management panel.
The location of the workspace directory.
The filename of the currently compiled project.
The name of the currently compiled project.
The common top-level directory of the currently compiled project.
The filename of the file opened in the currently active editor.
the directory containing the currently active file (relative to the common top level path).
The base name (without extension) of the currently active file.
The extension of the currently active file.
A string containing the names of all files in the current project.
The filename of the makefile.
The path to the currently running instance of CodeBlocks.
The ’shared’ directory of the currently running instance of CodeBlocks.
The plugins directory of the currently running instance of CodeBlocks.
The output file of a specific target.
The output directory of a specific target.
The output file’s base name (no path, no extension) of a specific target.
The output directory of the current target.
The object directory of the current target.
The name of the current target.
The output file of the current target.
The output file’s base name (no path, no extension) of the current target.
The build tool executable (compiler, linker, etc) of the current target.
The system language in plain language.
The character encoding in plain language.
Current date in the form YYYYMMDD (for example 20051228)
Current date in the form YYYY-MM-DD (for example 2005-12-28)
Timestamp in the form YYYY-MM-DD-hh.mm (for example 2005-12-28-07.15)
] Timestamp in the form YYYY-MM-DD-hh.mm.ss (for example 2005-12-28-07.15.45)
Plain language day of the week (for example ’Wednesday’)
These are identical to the preceding types, but are expressed relative to UTC.
The number of the days passed since an arbitrarily chosen day zero (January 1, 2009). Useful as last component of a version/build number.
This variable tosses a virtual coin (once per invocation) and returns 0 or 1.
A 16-bit positive random number (0-65535)
The variable are substituted through the command of the operating system.
Copy command for files.
Remove command for files.
Move command for files.
Make directory command.
Remove directory command.
Conditional evaluation will resolve to its true clause if
Conditional evaluation will resolve to its false clause if
Example
For example if you are using several platforms and you want to set different parameters depending on the operating system. In the following code the script commands of [[ ]] are evaluated and the <command> will be executed. This could be useful in a post-built step.
For maximum flexibility, you can embed scripts using the [[ ]] operator as a special case of variable expansion. Embedded scripts have access to all standard functionalities available to scrips and work pretty much like bash backticks (except for having access to CodeBlocks namespace). As such, scripts are not limited to producing text output, but can also manipulate CodeBlocks state (projects, targets, etc.).
Example with Backticks
The expression in backticks returns a list of all executables *.elf in any subdirectories. The result of this expression can be used directly by objdump. Finally the output is piped to a file named name.dis. Thus, processes can be automatted in a simple way without having to program any loops.
Example using Script
The script text is replaced by any output generated by your script, or discarded in case of a syntax error.
Since conditional evaluation runs prior to expanding scripts, conditional evaluation can be used for preprocessor functionalities. Built-in variables (and user variables) are expanded after scripts, so it is possible to reference variables in the output of a script.
inserts the title of the active project into the command line.
Access to name of the compiler executable.
Access to name of the linker executable.
Compiler flags
Linker flags
Compiler include paths
Linker include paths
Linker libraries
Source file (full name)
Source file directory without file name and file name extension.
Source file name without path info and file name extension.
Directory of executable without file name and file name extension.
File name of executable without path and file name extension.
File name extension of executable without path and file name.
Object file
Executable output file
Object Output Directory
Working as a developer on a project which relies on 3rd party libraries involves a lot of unnecessary repetitive tasks, such as setting up build variables according to the local file system layout. In the case of project files, care must be taken to avoid accidentially committing a locally modified copy. If one does not pay attention, this can happen easily for example after changing a build flag to make a release build.
The concept of global compiler variables is a unique new solution for CodeBlocks which addresses this problem. Global compiler variables allow you to set up a project once, with any number of developers using any number of different file system layouts being able to compile and develop this project. No local layout information ever needs to be changed more than once.
Global compiler variables in CodeBlocks are discriminated from per-project variables by a leading hash sign. Global compiler variables are structured; every variable consists of a name and an optional member. Names are freely definable, while some of the members are built into the IDE. Although you can choose anything for a variable name in principle, it is advisable to pick a known identifier for common packages. Thus the amount of information that the user needs to provide is minimised. The CodeBlocks team provides a list of recommended variables for known packages.
The member base resolves to the same value as the variable name uses without a member (alias).
The members include and lib are by default aliases for base/include and base/lib, respectively. However, a user can redefine them if another setup is desired.
It is generally recommended to use the syntax $(#variable.include) instead of $(#variable)/include, as it provides additional flexibility and is otherwise exactly identical in functionality (see Listing 3.12.1 and Abbildung 3.1 for details).
The members cflags and lflags are empty by default and can be used to provide the ability to feed the same consistent set of compiler/linker flags to all builds on one machine. CodeBlocks allows you to define custom variable members in addition to the built-in ones.
CodeBlocks will detect the most obvious cases of recursive definitions (which may happen by accident), but it will not perform an in-depth analysis of every possible abuse. If you enter crap, then crap is what you will get; you are warned now.
Examples
Defining wx.include as $(#wx)/include is redundant, but perfectly legal Defining wx.include as $(#wx.include) is illegal and will be detected by CodeBlocks Defining wx.include as $(#cb.lib) which again is defined as $(#wx.include) will create an infinite loop
All you need to do for using global compiler variables is to put them in your project! Yes, it’s that easy.
When the IDE detects the presence of an unknown global variable, it will prompt you to enter its value. The value will be saved in your settings, so you never need to enter the information twice.
If you need to modify or delete a variable at a later time, you can do so from the settings menu.
Example
The above image shows both per-project and global variables. WX_SUFFIX is defined in the project, but WX is a global user variable.
Sometimes, you want to use different versions of the same library, or you develop two branches of the same program. Although it is possible to get along with a global compiler variable, this can become tedious. For such a purpose, CodeBlocks supports variable sets. A variable set is an independent collection of variables identified by a name (set names have the same constraints as variable names).
If you wish to switch to a different set of variables, you simply select a different set from the menu. Different sets are not required to have the same variables, and identical variables in different sets are not required to have the same values, or even the same custom members.
Another positive thing about sets is that if you have a dozen variables and you want to have a new set with one of these variables pointing to a different location, you are not required to re-enter all the data again. You can simply create a clone of your current set, which will then duplicate all of your variables.
Deleting a set also deletes all variables in that set (but not in another set). The default set is always present and cannot be deleted.
As stated above, writing $(#var.include) and $(#var)/include is exactly the same thing by default. So why would you want to write something as unintuitive as $(#var.include)?
Let’s take a standard Boost installation under Windows for an example. Generally, you would expect a fictional package ACME to have its include files under ACME/include and its libraries under ACME/lib. Optionally, it might place its headers into yet another subfolder called acme. So after adding the correct paths to the compiler and linker options, you would expect to #include <acme/acme.h> and link to libacme.a (or whatever it happens to be).
This article will describe the process used in creating the nightly builds, and can be used as a guideline if you want to build CodeBlocks yourself. It is described as a sequence of actions.
In order to perform our build tasks, we will need several tools. Let’s create an ingredient list for our cooking experiments
Since the CodeBlocks developers build CodeBlocks using GCC, we might as well use that one under windows. The easiest and cleanest port is MinGW. This is the compiler distributed with CodeBlocks when you download the official package. We will stick to version 3.4.5, which works nicely.
First, a brief explanation of MinGW components:
I would suggest extracting (and installing for the GDB) everything in the C:\MinGW directory. The remainder of this article will assume that this is where you have put it. If you already have an installation of CodeBlocks that came bundled with MinGW, I still advise you to install MinGW as described here. A compiler does not belong under the directory tree of an IDE; they are two separate things. CodeBlocks just brings it along in the official versions so that the average user does not need to bother with this process.
You may need to add the bin directory of your MinGW installation to your path. An easy way to do this is with the following command at the command prompt:
For [?] a project description CodeBlocks.cbp is available. If you load this project file in CodeBlocks then you are able to build CodeBlocks from sources. All we need to do is get hold of a pre-built version CodeBlocks.
First, download a nightly build. You can make your selection from here. The nightly builds are unicode versions, containing the core and contributed plug-ins.
Next, unpack the 7-zip file to any directory you like. If you don’t have 7-zip, you can download it for free from [?].
Now, CodeBlocks needs one more dll to work correctly: the WxWidgets dll. You can also download it at the nightly builds forum. Just unzip it into the same directory that you unpacked the CodeBlocks nightly build. It also needs the mingwm10.dll. It’s in the bin directory of our MinGW installation. So, it’s important to make sure the bin directory of your MinGW installation is in your path variable.
Finally, start up this new nightly build of CodeBlocks. It should discover the MinGW compiler we just installed.
In order to be able to retrieve the latest and greatest CodeBlocks sources, we need to install a Version Control System.
The CodeBlocks developers provide their sources through the version control system[?]. So, we need a client to access their svn repository of sources. A nice, easy client for Windows is [?], which is freely available. Download and install it, keeping all suggested settings.
Now, go create a directory wherever you like, for example D:\projects\CodeBlocks. Right click on that directory and choose from the pop-up menu: svn-checkout. In the dialog that pops up, fill in the following information for Url of Repository:
svn://svn.berlios.de/codeblocks/trunk
and leave all other settings as they are.
Now be patient while TortoiseSVN retrieves the most recent source files from the CodeBlocks repository into our local directory. Yes; all those CodeBlocks sources are coming your way!
For more info on SVN settings, see info on SVN settings. If you don’t like an Explorer integration or look for a cross-plattform client you might want to have a look at RapidSVN..
[?] is a platform abstraction that provides an API to support many things such as GUI, sockets, files, registry functionality. By using this API, you can create a platform independent program.
CodeBlocks is a wxWidgets (here after: wx) application, that means if you want to run CodeBlocks you needed the wx functionality. This can be provided in a couple of ways. It could be a .dll or a static library. CodeBlocks uses wx as a dll and this dll can also be downloaded from the nightly build section of the forum.
However, if we want to build a wx application, we need to include the headers of the wx sources. They tell the compiler about the functionality of wx. In addition to those header files, our application needs to link to the wx import libraries. Well, let’s take it step by step.
Wx is provided as a zip file of it’s sources, so we need to build that ourselves. We already shopped for the MinGW compiler, so we have all the tools we need at hand.
Next, let’s unzip the wx sources into C:\Projects so we will end up with a wx root directory like this: C:\Projects\wxWidgets-2.8.9. Next unzip the patch into the same directory letting it overwrite files. Note that we are going to refer to the wx root directory from now on as <wxDir>
Now, we are going to build the wxWidgets. This is how we do it:
First, make sure C:\MingGW\bin is in your path, during the build some programs will be called that reside in the the MinGW\bin directory. Also, Make has to be version 3.80 or above.
Now it is time to compile wxWidgets. Open the command prompt and change to the wxWidgets directory:
We are now in the right place. We are first going to clean up the source:
Once everything is clean, we can compile wxWidgets:
This is going to take some time.
For making the debug build, follow these steps:
Well have a little look in the directory (<wxDir>\lib\gcc_dll) now. The import libraries and the dll have shown up and there should also a mswu\wx subdirectory at that position containing setup.h.
Congratulations! You have just built wxWidgets!
Let’s do some more preliminary tasks before we get to the real deal of compiling CodeBlocks.
During the build of CodeBlocks, several resources are going to be zipped in zip files. Therefore, the build process should have access to a zip.exe. We have to download that zip.exe and put it somewhere in our path. A good place is: MingW\bin.
You can download zip.exe for free from this site and this is a direct link(32bit) to the most recent version at the time of this writing.
Once downloaded, simply extract zip.exe to the appropriate location.
With this function the SVN revision of the Nightly Builts is updated in the sources. The file can be found in the main directory of the CodeBlocks sources.
Now, open the project CodeBlocks.cbp in CodeBlocks. Generate CodeBlocks by starting the build process. After the creation of CodeBlocks, the generated files with the debug information can be found in the devel subdirectory. By calling the batch file update.bat from the source directory, the files are copied to the output subdirectory and the debug information is stripped.
When generating under Linux, the following steps are necessary. In this example we assume that you are in the CodeBlocks source directory. Under Linux, the environment variable PKG_CONFIG_PATH must be set. The <prefix> directory has to contain the codeblocks.pc file.
Afterwards, configure the global variables via ’Settings’ /’Global Variables’ .
Variable cb
For the cb variable, set the base entry to the source directory of CodeBlocks.
Variable wx
For the wx variable, set the base entry to the source directory of wx (e.g.
In the CodeBlocks project, the project variable WX_SUFFIX is set to u. This means that, when generating CodeBlocks linking will be carried out against the *u_gcc_custom.dll library. The official nightly Builts of CodeBlocks will be linked against gcc_cb.dll. In doing so, the layout is as follows.
The <VENDOR> variable is set in the configuration file compiler.gcc. To ensure, that a distinction is possible between the officially generated CodeBlocks and those generated by yourself, the default setting VENDOR=custom should never be changed.
Afterwards create the workspace ContribPlugins.cbp via ’Project’ /’Build workspace’ . Then execute update.bat once more.
Variable wx bei globalen Variablen konfigurieren. Configure the wx variable with the global variables.
debug CodeBlocks. Start CodeBlocks in the output directory and load CodeBlocks.cbp as the project. Then set the breakpoint and start with ’Debug and Run’ (f8).
This brings us to the last preliminary task. The CodeBlocks code can be divided into 2 major parts: the core with internal plug-ins, and the contributed plug-ins. You always need to build the core/internal parts before building the contrib part.
To build the internal part, you can use the CodeBlocks project file which you can find at: <cbDir>\src\CodeBlocks.cbp. Our CodeBlocks master directory is from now one mentioned as <cbDir>, by the way. A workspace is something that groups several projects together. To build the contrib plug-ins, they can be found at
But, let’s create a workspace containing everything. Let’s put that workspace in the master directory <cbDir>. Just use a regular text editor and create a file with the name CbProjects.workspace and give it the following content :
We will use this workspace to build all of CodeBlocks.
Finally we have arrived at the final step; our final goal. Run the CodeBlocks executable from your nightly build download. Choose Open from the File menu and browse for our above created workspace, and open it up. Be a little patient while CodeBlocks is parsing everything, and CodeBlocks will ask us for 2 global variables, these global variables will tell the nightly CodeBlocks where it can find wxWidgets (remember : header files and import libraries) and where it can find .... CodeBlocks, this is needed for the contrib plug-ins, they need to know (as for any user created plug-in) where the sdk (CodeBlocks header files) are. These are the values in our case :
Now go to the Project Menu and choose (re)build workspace, and off you go. Watch how CodeBlocks is building CodeBlocks.
Once the build is complete, open up a console in <cbDir>/src and run the command update.bat. This will transfer all built deliverables from <cbDir>/src/devel to <cbDir>/src/output. In addition, it will strip out all debugging symbols. This step is very important - never ever forget it.
Now you can copy the wx dll in both that output and the devel directory.
Then you can close CodeBlocks. That was the downloaded nightly remember?
Time to test it. In the output directory, start up the CodeBlocks.exe. If everything went well, you’ll have your very own home-built CodeBlocks running.