Wie strukturiert Ihr Eure Entwicklungsverzeichnisse?

[Assertor]

Hi,

da mit der Zeit bei uns Entwicklern ja so einige Dateien zusammenkommen, möchte ich gerne wissen, wie Ihr Eure Dateien und Projekte strukturiert?

Es geht mir nicht um Versionskontrolle und deren Struktur, sondern um die lokale Struktur von Projekten, Includes, Tutorials, Präsentationen, BuildTools, Entwicklungstools, etc.pp. Ich erhoffe mir ein paar gute Anregungen aus der Praxis anderer Entwickler. Interessant ist auch, ob Ihr Includes projektübergreifend verwendet oder dem einzelnen Projekt zuordnet (gut, mit Versionskontrolle ja automatisiert lösbar).

Gruß Assertor

[HeinzJ]

Soweit es die Verzeichnisstruktur und die Benennung betrifft, versuche ich meine Projekte nach dem Beispiel von Java Packages zu organisieren. Bei der Benennung von Dateien nach diesem System (z.B. "org.firma.project.forms.main.pas") wird das ganz auch schön in der Modellansicht von Delphi abgebildet.

[Assertor]

Hi Heinz,

danke für die Antwort!

Zitat von HeinzJ:

Soweit es die Verzeichnisstruktur und die Benennung betrifft, versuche ich meine Projekte nach dem Beispiel von Java Packages zu organisieren. Bei der Benennung von Dateien nach diesem System (z.B. "org.firma.project.forms.main.pas") wird das ganz auch schön in der Modellansicht von Delphi abgebildet.

Eine Möglichkeit, wobei das teilweise bei den Dateinamen ja richtig lang werden kann...

Mich interessiert aber hauptsächlich die Verzeichnisstruktur, also z.B.

Zitat:

d:\entwicklung\projekte\abc\
d:\entwicklung\includes\
d:\entwicklung\beispiele\
d:\entwicklung\dokumente\

Das ganze sieht bei mir aber erheblich anders als im Beispiel aus, daher frag ich wie Ihr die "zusätzlichen" Sachen, also Tutorials, Code-Snippets, Beispiele, Includes etc. unterbringt.

Gruß Assertor

[mirage228]

Naja, grundsätzlich strukturiere ich erstmal nach Projekten. Sollte es Klassen etc. geben, die man projektübergreifend verwenden kann, gibt es dafür einen "Common/Shared"-Ordner innerhalb des "Entwicklungs"-Ordners.
Innerhalb der Projekte nehme ich eine weitere Struktierung nur dann vor, wenn es die Projektgröße erfordert. Etwa ein Ordner "Klasses/Types" für die Programm-Logik- und sonstige Klassen.

Viele Grüße

[Muetze1]

Code:

x:\Docs\
x:\Docs\Electronic\
x:\Docs\Projects\
x:\Docs\External\
x:\Docs\External\Standards\
x:\Docs\External\Standards\T13 ATAPI\
x:\Docs\External\Standards\XML\
x:\Docs\External\Standards\...

x:\Sources\
x:\Sources\Repositories\
x:\Sources\Repositories\[RepositoryRoot 1]\
x:\Sources\Repositories\[RepositoryRoot 1]\

x:\Sources\Experimental\
x:\Sources\Experimental\Test DEC Hashing\ (*g*)
x:\Sources\Experimental\...

x:\Sources\Releases\
x:\Sources\Releases\ACETAO\
x:\Sources\Releases\...\
x:\Sources\Releases\Shared\
x:\Sources\Releases\Tools\

x:\Sources\Installs\
x:\Sources\Installs\[Projektname]\

[] - sind Platzhalter für die entsprechenden Namen
... - weitere Elemente nach gleichen Schema...
x:\Sources\Releases\ - enthält Binaries
x:\Sources\Releases\Tools\ - Tools u.a. für das Command Line Build System, in PATH enthalten
x:\Sources\Releases\Shared\ - DLLs die von vielen Projekten benötigt werden, in PATH enthalten

Viele Pfade sind per Environment konfiguriert und werden in den jeweiligen Projekten auch nur über die Environment referenziert. Dadurch kann jeder sein Laufwerk x oder den Pfad sonstwo haben.

Bei den Projekten immer ausgehend vom Projektroot:

Code:

\Build\
\Bin\
\Include\
\obj\
\Sources\
\Docs\

Projektdatei liegt im Root, alle Quellen in Sources. Docs zum Projekt unter Docs, u.U. auch noch ein Unterverzeichnis wodrin die Source Code Dokumentation generiert wird (DoxyGen, Doc-O-Matic). Obj enthält allte intermediates (.o, .obj, .dcu, etc), Bin alle Ausgaben (.lib, .tds, .exe, .dll). Include existiert nur, wenn es sich um Delphiquellen handelt, welche auch von C++ benutzt werden. Darin werden die generierten .hpp's abgelegt. Bei einem reinem Delphi Projekt gibt es den Pfad nicht, bei einem reinen C++ Projekt auch nicht, dort sind die Header passend zu ihren Sources in Sources\. Build enthält die Build Skripte für das Projekt.

Für Bibliotheken und Klassen welche projektübergreifend verwendet werden (u.a. auch Komponenten) und im Quellcode vorliegen, gibt es entsprechend ein Repository.

[Assertor]

Hi,

@mirage228: Danke fürs Mitmachen!

@Muetze1: Danke für die ausführliche Antwort, ich sehe da viele Gemeinsamkeiten. Besonders den Test Ordner fürs DEC Hashing Ich werde glaube ich mal bei mir etwas umsortieren...

Andere Beiträge sind natürlich gerne willkommen!

Gruß Assertor

[mirage228]

Hallo,

Noch ein paar Ergänzungen meinerseits. Hatte den Ausgangspost nur auf Quelltext und Projektdateien bezogen, nicht auf die restlichen Dinge wie Dokumentationen.

Also ähnlich wie Muetze habe ich auch ein "Bin"-Verzeichnis, wo die Output-EXE/DLL-Dateien reinkommen. Setups und Installer hingegen haben bei mir einen eigenen Ordner innerhalb des Projektverzeichnisses ("Setup") - mitsamt dem Installer-Script.
Für CHM-Hilfedatei-Projekte oder Dokumentationen habe ich ein eigenes Unterzeichnis "Hilfe" oder "Help" gepackt.
DCU und OBJ Dateien belasse ich, wie die PAS-Dateien und die Projektdateien im Hauptverzeichnis des jeweiligen Projektes. Der Übersicht halber setzte ich aber im Explorer die Sortierung nach Dateitypen mit dazugehöriger Gruppierung eingeschaltet. Ab einer bestimmten Größe des Projektes würde ich aber auch zu einer Aufteilung wie es Muetze hat, tendieren.
Ältere Releases/Installer sowie die dazugehörigen Quelltexte als ZIP gepackt habe ich zusammen in einem Verzeichnis "OldVersions".

Viele Grüße,

David

[Hansa]

Bei mir hat jedes Projekt eigenes Verzeichnis. Also in der Richtung \Projekt. Und es gibt ein Verzeichnis \gemeinsam. Und genau die werden auch immer gesichert. Mit "Windows-Standard" werden die Pfadnamen einfach zu lang. Das ist unpraktikabel, z.B. für BAT etc. Diverse Dateitypen extra zu behandeln, was soll das ?

[mjustin]

Zitat von Assertor:

Hi,

da mit der Zeit bei uns Entwicklern ja so einige Dateien zusammenkommen, möchte ich gerne wissen, wie Ihr Eure Dateien und Projekte strukturiert?

Es geht mir nicht um Versionskontrolle und deren Struktur, sondern um die lokale Struktur von Projekten, Includes, Tutorials, Präsentationen, BuildTools, Entwicklungstools, etc.pp. Ich erhoffe mir ein paar gute Anregungen aus der Praxis anderer Entwickler. Interessant ist auch, ob Ihr Includes projektübergreifend verwendet oder dem einzelnen Projekt zuordnet (gut, mit Versionskontrolle ja automatisiert lösbar).

Gruß Assertor

In meinen Projekten gibt es in der Regel neben den Ordnern source, docs, libraries, make, etc einen target Ordner. Alle Builds laufen über ein Makefile mit Apache Ant, wobei die Sourcen und sonstigen benötigten Dateien erst in dieses Target Verzeichnis kopiert werden. Der Build findet dann nur in diesem target Verzeichnis statt. Die fertigen Installationsdateien (Setup.exe, Demo.zip) liegen am Ende dann auch im target Verzeichnis.

Ein Vorteil des automatischen Builds ist, dass man genau die Dateien zum Kompilieren verwendet die auch ausgeliefert werden (durch automatisches Umkopieren zu Beginn des Builds in das target Verzeichnis). Dadurch fällt es sehr viel schneller auf, wenn ein Build wegen fehlender Abhängigkeiten fehlschlägt. Auch 'falsch positiv'-Fehler kann man so vermeiden (wenn man in der Entwicklungsumgebung kompilieren kann, weil eine DCU noch dort vorhanden ist - aber die zugehörige Quelldatei fehlt).

Apache Ant ist zum Bauen und Testen, und auch zur Nachbearbeitung (Komprimierung, Toolaufrufe z.B. Doxygen oder Doc-O-Matic) sehr gut geeignet. An unterschiedliche Entwicklungsumgebungen kann man es mit einer build.properties Datei anpassen, in der man die Pfade zu Compilern, Tools und zentralen Libraries einträgt und leicht z.B. auf andere Laufwerke umstellen kann. Auch das Eintragen von Copyright-Headern und andere Textbearbeitungen gehen damit sehr einfach, z.B. aus einem Innosetup-Skripttemplate mit Variablenersetzung das für den Build benötigte Skript mit Produktname/versionsnummer etc. generieren.

[Assertor]

Hi,

nachmal ein Dankeschön an alle, die mitgemacht haben. Gerade die Ideen mit den Variablen für die Pfade und den Buildautomatisierungen haben mir interessante Anregungen gegeben. Jetzt ist alles wieder ordentlich

Gruß Assertor