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

[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*