Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden

[hoika]

Hallo,

Zitat:

uNUTSConstants

Genau sowas meine ich.
Die Konstanten werden irgendwo gebraucht, aber nicht in der Projektdatei.
Ich mache das uses immer dort, wo die Unit benutzt wird.
Das zusätzlich in die dpr zu bringen, damit sie aufgrund des Ablage-Pfades gefunden wurde, finde ich halt nicht sehr zielführend.

Deshalb ja auch meine Frage, wie das andere machen.

[TigerLilly]

Zitat:

Deshalb ja auch meine Frage, wie das andere machen.

Bibliothekscode + 3rdParty + RTL + VCL/FMX: Bibliotheks+Suchpfad, wobei gleiche Teile via ($XYZ) abgekürzt werden.

Projektspezifische Dateien: DPR

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1425494)

Nur wen man alle Forms automatisch erzeugen lässt, das mache ich eben nicht.

Wer macht das schon...

Ich habe sogar VCL-Projekte (FMX ist da ja flexibler), bei denen dynamisch das MainForm bestimmt wird - und das natürlich nicht in der DPR!

Trotzdem sind alle Projekt-spezifischen Units in der DPR aufgelistet. Insbesondere wenn man mit Frames, Datenmodulen und/oder Visual Inheritance arbeitet ist das in der Regel unverzichtbar.

Bisher habe ich noch jedes Projekt, bei dem ich irgendwie beteiligt war/bin so umgestellt. Alle(!) Entwickler haben danach ein wesentlich stabileres und angenehmeres Arbeiten mit der IDE bestätigt.

Ein für mich entscheidender Vorteil dieser Herangehensweise ist, daß ich genau kontrollieren (und such sofort sehen) kann, welche Units im Projekt benötigt werden. Der Projekt-Suchpfad wird auf das Nötigste beschränkt, damit nicht versehentlich eine Unit eingebunden wird, nur weil sie im Suchpfad gefunden wird. Die Projekt-Units sind in Unterverzeichnissen hierarchisch abgelegt, so daß ich in der Projektverwaltung eine übersichtliche Baumstruktur bekomme. Bis auf wenige Ausnahmen gibt es keine Units im Projekt-Verzeichnis selbst, sondern nur darunter. Aber diese Unterverzeichnisse tauchen auf keinen Fall in dem Projekt-Suchpfad auf. Der ist ausschließlich für die verwendeten Bibliotheken reserviert.

Ach ja, zum Projekt gehörige Units (in der DPR/DPROJ) sind über IDE-Insight (F6 oder Strg-<Punkt>) auffindbar. Units im Suchpfad in der Regel erstmal nicht.

Aber das muss jeder für sich entscheiden.

[Delphi.Narium]

Also, ich hab mir vor kurzem angewöhnt, den Bibliothekspfad und den Suchpfad auf ein Minimum zu reduzieren.

Grund: Das Kompilieren dauerte idiotisch lange.

Mit dem FileMon von SysInternals hab' ich mal mitloggen lassen, was da so alles auf der Festplatte passiert.

Delphi sucht jede mit Uses irgendwo eingebundene Datei in allen Pfaden, die in Bibliotheks- und Suchpfad stehen, bis sie gefunden wurde. Zuerst wird überall nach der .pas gesucht, wenn die nicht gefunden wird, nochmal das Ganze mit der .dcu. Erst wenn das erfolglos ist, wird 'ne Fehlermeldung ausgegeben. Da kommen dann schnell etliche tausend erfolglose Dateizugriffe zustande.

Das Ergebnis des FileMon speichere ich mir dann in eine Datei und mit 'nem Pascal-Script für meinen Editor, werte ich diese Datei aus. Man kann gut die erfolgreichen Zugriffe des Compilers von den Fehlern untershcheiden. Für die erfolgreichen Zugriffe schreib' ich mir eine Zeile für die DPR. Die wird entsprechend ergänzt und enthält dann alles, was "irgendwo" gefunden wurde.

Was nicht gefunden wurde, wird mit 'ner rekursiven Dateisuche durch das Script "aufgestöbert" und kommt dann ebenfalls in die DPR. Das Script durchsucht nur von mir vorgegeben Verzeichnisse, so dass Bibliotheken und Fremdkomponenten nicht gefunden werden.

Sollte dann beim Kompilieren noch Sachen nicht gefunden werden, wird dafür entweder der Such- oder der Bibliothekspfad ergänzt oder die Datei ins Projekt aufgenommen, also die DPR ergänzt.

Die DPR kann schonmal recht groß werden, da sie aber für die gewöhnliche Programmierung eh kaum benötigt wird (wann braucht man dort schon irgendeine Programmlogik), ist das für die Entwicklung eigentlich eher egal.

Vorteil: Das Kompilieren wird deutlich schneller, bei sehr großen Projekten kann die Beschleunigung im Minutenbereich liegen, jedenfalls dann, wenn man mal ein Projekt neu erstellen lässt.

[Rollo62]

Zitat:

Insbesondere wenn man mit Frames, Datenmodulen und/oder Visual Inheritance arbeitet ist das in der Regel unverzichtbar.

Ich kann jedenfalls gut darauf verzichten, hat mir oft genug Kopfzerbrechen gemacht.
In einem Main_Modules Unit kann ich alles per Code zusammenfassen was gebraucht wird,
statt per Designer in der DPR.

Visuelles Ableiten, oder das visuelle Verbinden von Form/Datenmodul versuche ich möglichst zu Vermeiden.
Bindings kann man per Runtime Code viel zuverlässiger und wartbarer machen.
Kommunikation kann man über Interfaces optimieren, oder noch besser über Events komplett entkoppeln, damit kann ich im Extremfall sogar mit 0 Form/DataModul Bindings auskommen.

Vorteil:
Main DPR bleibt quasi leer, und kann auch mal sehr schnell neu angelegt werden (z.B. von 10.2.3 auf 10.3), damit man die aktuellsten IDE-Settings mitnehmen kann.

Es könnte natürlich anders werden wenn man zig Fremdkomponenten mit zig Fremdphilosophien einbindet.
Genau deshalb habe ich möglichst alle Fremdkomponenten rausgeworfen, und entscheide mich sehr bewusst für einzelne Komponenten, statt immer gleich ein ganzes Sammelsurium vom KomponentenSets reinzuerfen, von denen man nur 5% benutzt.
In neuen Projekten nutze ich möglichst Delpi pur und nur direkt ladbare Libraries, wie meine eigene oder Spring4D.

Ein "unverzichtbar" sehe ich dabei gar nicht, seitdem ich das versuche sehr extrem zu enkoppeln kann ich ruhiger schlafen.

Ich möchte hier niemanden zu irgendwas überreden, nur mal miteinander austauschen welche alternative Konstruktionen es geben könnte, mit welchen Vor- und Nachteilen.
Ich verfeinere meine Philosophie und Strategien auch ständig, und versuche so optimal wie möglich zu arbeiten, deshalb sehe ich mir immer gerne andere, und neue Lösungsvorschläge an.
Ein "NUR DAS ist richtig" lasse ich dabei eher nicht gelten, dazu zeigt uns z.B. JavaScript, PHP und andere was mit alternativen, vormals belächelten Konzepten möglich sein kann.
Da sieht Delphi eher alt aus.

[hoika]

Hallo,
ich finde die Diskussion hier sehr gut und produktiv!
*FileMon anwerf*