Global compiler variables

März 25th, 2008 | Kategorien: Programmierung | Tags:

Da habe ich doch tatsächlich was gefunden, was mir an Code::Blocks besser gefällt als am Visual Studio: Globale Compiler Variablen.

Jeder, der es schonmal gewagt hat in einem Team oder für mehrere Plattformen zu programmieren kann ein Lied von diversen Problemen externen Bibliotheken singen. Jeder, der das Projekt selber kompilieren möchte benötigt gewisse Header und Librarys, meistens in speziellen Versionen.

Normalerweise erstellt man für jedes Projekt eine Liste und lässt die Leute ihre Sachen selber zusammensuchen und die Einstellungen selber vornehmen. Code::Blocks kann immerhin den zweiten Schritt, die Einstellungen, drastisch vereinfachen.

Anstatt sich auf Umgebungsvariablen wie $(OGRE_HOME) zu verlassen, wie es das Visual Studio tut, oder einen Ordner namens “Dependencies” oder ähnlich mitzuliefern, bringt Code::Blocks eigene Umgebungsvariablen ins Spiel. Das hat folgende Vorteile:

  • Man muss nicht an diversen Betriebssystemeinstellungen rumspielen um ein Projekt zu kompilieren.
  • Man kann “Sets” aus Variablen anlegen, z.B. für einzelne Projekte die die gleichen Bibliotheken in verschiedenen Versionen benötigen. Mit den Betriebssystemweiten Variablen geht das, zumindest unter Windows, nicht.
  • Code::Blocks fordert das ausfüllen dieser Variablen in einem eigenen Dialog ein, man kann die Abhängigkeiten folglich garnicht übersehen.

Der Editor für die globalen Variablen gewinnt sicherlich keinen Schönheitspreis, ist aber zweckmäßig:

Compilervariablen mit Code::Blocks

Unschwer zu erkennen: In diesem Fall liegt ein Projekt vor, dass PostgreSQL als Datenbank einsetzt. Den Projekteigenschaften fügt man nun noch die Suchpfade für die Header und die Libs hinzu. Das geschieht mit folgendem Syntax:

$(#postgresql.include)

Schritt für Schritt: Die “$(Name)” Schreibweise ist der geläufige Syntax für Umgebungsvariablen aller Art. Code::Blocks benötigt nun eine Raute vor den Namen um zu verdeutlichen, dass es sich um “seine” Art von Umgebungsvariable handelt. Mit dem .include wird dann verdeutlicht, auf welchen Pfad bzw auf welchen Teil der Variable zugegriffen werden soll. Im Beispiel folglich auf die Headerdateien. Für den Linker würde man das .include folglich durch .lib ersetzen.

Wenn Code::Blocks nun auf eine unbekannte Variable stößt, zwingt es den Anwender über den obigen Dialog, diese zu deklarieren. Tut er dies nicht, bricht die Kompilierung ab. Aber man weiss dann immerhin recht genau, welche Bibliothek noch fehlt.

No comments yet.