Organisation der Projekt-Dateien

[Glocke]

Heyho,

ich finde immer wieder Baustellen ^^ Die neu'ste: Organisation der Projekt-Dateien. Ich arbeite mit CodeBlocks an meinem Iso-RPG-Projekt und versuche parallel dazu eine Engine abzuspalten. Aktuell habe ich folgende Struktur:

• /data
  beeinhaltet Spiel-Daten (Grafiken, Sounds, INI-Dateien; div. Unterverzeichnisse dazu)
• /bin
  beeinhaltet Binär- und Objekt-Dateien - wegen Kompilierung
• /src
  beeinhaltet cpp und hpp Dateien
• /src/core
  alles was zum "Kern" gehört: Sprite Klasse, div. Widget Klassen, ImageManager, Klassen für das tile-basierte Grid, das Rendering usw.
• /src/net
  alles was zur Netzwerkkommunikation gehört, vgl. https://github.com/cgloeckner/networking
• /src/game
  eigentliche Spiellogik usw.

Dabei gefällt mir die Organisation meines src-Verzeichnisses ganz und gar nicht. Bei anderen Projekten habe ich eine Unterteilung in src- und include-Verzeichnisse festgestellt. Ich vermute das ist sinnvoll um - wenn man eine dynamische Library aus dem Projekt macht - die Header-Files zentral hat (die braucht man ja wenn man die dyn. Lib verwenden will).

Jetzt überlege ich, ob ich das auch so aufbaue - bzw. ob ich meine Engine zum Schluss als dyn. Lib meinem Spiel (dynam. gelinkt) beilege - oder wie ich generell die Daten- und Ordnerstruktur verbessern könnte.

Habt ihr da ein paar Ideen für mich?

LG Glocke

[Xin]

Im Prinzip hast Du alles gesagt... ^^

Ich habe eine Ähnliche Struktur wie Du. Bei mir liegt alles in einem Source-Verzeichnis (dass allerdings den Namen meiner Domain hat, also de/xsd/, bzw. org/proggen/.

Header und Sourcedateien habe ich in einem Verzeichnis, auf der Arbeit haben wir das getrennt.
Es zu trennen ist sauberer, beim Anlegen einer neuen Klasse nervt mich dafür der laufende Wechsel zwischen den Verzeichnissen.

Wenn eine Lib entsteht kann man notfalls auch ein Make-File schreiben, dass aus dem Quelltext die Headerfiles in ein neues Paket zieht. - imho...

Ergo: Ich habe eine ähnliche Aufteilung. Wenn es Dir nicht gefällt, probiere was anderes.... im schlimmsten Fall sammelst Du Erfahrung.

[Glocke]

Hi, inzwischen habe ich gerenell folgende Struktur: include/ für Header-Dateien, src/ für Implementierungen. Im Codeblocks konfiguriere ich den include-Pfad für die Header-Files (vgl. -I-flag von GCC).

Aktuell überlege ich, wie ich mehrere parallele, aber aufeinander aufbauende Projekte verwalte. Zum Beispiel liegt im networking-Ordner mein Netzwerk-Framework (was ihr auch auf GitHub findet). Das verwende ich widerum in meinen Engine-Projekt, will aber die Dateien nicht reinkopieren, sondern lieber direkt den Quellcode aus dem networking-Verzeichnis (was parallel zu engine liegt) direkt verwenden.

Allerdings möchte ich die Projekte nicht zusammenfassen, weil ich (a) die Netzwerk-Geschichte auf GitHub bereitstelle und (b) das Ziel des Frameworks weitaus allgemeiner ist, als das der Engine. Welche Möglichkeiten habe ich nun?

Ich könnte den Include-Pfad (für das Engine-Projekt) um ../networking/include erweitern. Dann fehlt mir aber noch der Verweis auf meine .cpp-Dateien - oder ich bündle das networking-Framework zu einer statischen Library und füge die bein Bauen der Engine mit ein. Allerdings weiß ich nicht, ob mir das wieder vielleicht andere Nachteile bringt.

LG Glocke

[Xin]

Solange die Projekte scharf voneinander getrennt sind und keine Abhängigkeiten haben, rate ich Dir statische Libs zu bauen.

Ich bin hier etwas spät dran, ich habe ein paar hunderte, eventuell tausend Klassen, die wunderbar miteinander agieren, aber eben Abhängigkeiten besitzen. Das wieder auseinander zu bauen, um das raus kleinere, unabhängige Projekte zu machen, ist noch eine Großbaustelle in Planung bei mir.

[Glocke]

Solange die Projekte scharf voneinander getrennt sind und keine Abhängigkeiten haben, rate ich Dir statische Libs zu bauen.

Für meine Engine werde ich das vermutlich machen. Beim Netzwerk-Modul besteht (bis auf die JSON-Implementierung) alles aus Headern. Da bietet es sich vllt. an das ganze Framework "header-only" aufzubauen und nur die Header zu inkludieren.

LG Glocke