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

[hoika]

Hallo,
ich habe hier 2 Projekte, die sehr viele Ordner hat,
und wenn ich viel sage, meine ich auch viel.
Beide Projekte benutzen die gleiche Ordnerstruktur.

Bisher standen alle Dateien mit Suchpfad in der DPR.
Das will ich ändern. Ich will die da raushaben.

Tools/Optionen/ Bibliothek Win32 ist "voll".

Ich habe packe im Moment die Ordner in die Umgebungsvariable PATH, also den globalen Suchpfad. Aber dessen Länge ist wohl begrenzt (4096?).
Jetzt habe ich eine Umgebungsvariable Suche1, packe dort die folgenden Pfade rein und binde diese unter Tools/Optionen/ Bibo Win32/Suchpad mit $(Suche1) ein.
Mittlerweise bin ich bei Suche2 ...

Wie macht ihr das?

[bernau]

Ich habe in meinen Projekten auch viele Unterverzeichnisse gehabt (und habe sie teilweise immer noch).

Ich habe damit begonnen die Units in "ganz wenige" Verzeichnisse zu verschieben und dafür mache ich ausgiebigen Gebrauch von Namespaces, was wieder eine gewisse Ordnung bringt.

Das ist aber insgesammt eine Geschmacksache.

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1425320)

Bisher standen alle Dateien mit Suchpfad in der DPR.
Das will ich ändern. Ich will die da raushaben.

Warum? Es hat entscheidende Vorteile, wenn alle Units, die zum Projekt gehören, auch in der DPR aufgeführt sind.

Bei reinen Bibliotheken ist das was anderes.

Meine Projekte enthalten immer alle projekt-relevanten Units. Die Suchpfade im Projekt enthalten nur die benötigten Bibliotheken. Die globalen Bibliothekspfade sind auf die Delphi-eigenen Pfade beschränkt. Ich möchte nicht versehentlich irgendwelche Units verwenden, die zufällig gerade im Bibliothekspfad gefunden werden.

[CCRDude]

Irgendwann habe ich diesen Schritt (Pfade aus DPR raus und "globaler") auch mal gemacht und mich hinterher über die Arbeit geärgert, das alles zurück zu ändern.

Spätestens wenn man den Code teilt und Mitarbeitern etliche Einzelpfade mitteilen muss, wird's nervig. Auch schon nur, wenn man CI auf einer separaten Maschine verwenden will.

Wegen Unterschieden in Versionen von externen Paketen habe ich die sowieso inzwischen gerne pro Projekt in spezifischer Version, und daher relative Pfade die sich gar nicht verallgemeinern lassen.

Ich weiß, dass das keine hilfreiche Antwort auf die Frage ist, würde aber trotzdem anregen, die Motivation zu diesem Schritt zu überdenken.

[Rollo62]

Zitat:

Zitat von bernau (Beitrag 1425323)

Ich habe damit begonnen die Units in "ganz wenige" Verzeichnisse zu verschieben und dafür mache ich ausgiebigen Gebrauch von Namespaces, was wieder eine gewisse Ordnung bringt.

Mache ich auch so.
Hat aber Vor- und Nachteile:

Wenige oder Ein Unterverzeichnis:

• Vorteil : Einfaches Einpflegen der Suchpfade (im Idealfall nur einer).
• Nachteil: Verwaiste Links zu eigentlich unbenutzten Units werden trotdem eingebunden.
  Macht dann keinen Spass solche "Uses"-Fehler zu finden.

Viele Unter-Verzeichnisse:

• Vorteil : Nimmt man ein Verzeichnis aus dem Suchpfad sind wirklich alle Units darin nicht mehr erreichbar.
• Nachteil: Man MUSS immer alle Unterverzeichnisse sauber einpflegen

[jaenicke]

Wir machen das so, dass wir gemeinsame allgemeine Units haben und diese in einem eigenen Package vorher kompilieren, genauso wie Fremdkomponenten. Das geht inklusive Eintragung der Pfade usw. alles per Batchdatei.

In den Projekten sind dann alle Units direkt eingebunden, die zu dem Projekt selbst gehören.

Auf diese Weise sind Units wie Common.Utils.StringTools usw., die wirklich allgemeinen Charakter haben, nicht in allen Projekten drin, was die Zeit zum Erzeugen der Projekte deutlich reduziert. Andererseits ist der Aufwand für die Benutzer recht gering. Lediglich das Pflegen ist mit einem gewissen Aufwand verbunden, der aber abgesehen vom Initialaufwand auch sehr überschaubar ist. Und das macht auch nur einer und nicht alle.

[hoika]

Hallo,
danke für die vielen Antworten, hilft mir aber in dem Fall nicht wirklich ;)

Zitat:

Warum? Es hat entscheidende Vorteile, wenn alle Units, die zum Projekt gehören, auch in der DPR aufgeführt sind.

Weil Delphi immer alle Units aufmacht.

Zitat:

weniger Verzeichnisse

Ja, würde ich ja machen, aber der beteiligte Software-Architekt findet das gut.


PS: Prinzipiell will ich auch, dass alle Rechner die gleiche Konfiguration haben.

[peterbelow]

Zitat:

Hallo,
ich habe hier 2 Projekte, die sehr viele Ordner hat,
und wenn ich viel sage, meine ich auch viel.
Beide Projekte benutzen die gleiche Ordnerstruktur.

Bisher standen alle Dateien mit Suchpfad in der DPR.
Das will ich ändern. Ich will die da raushaben.

Tools/Optionen/ Bibliothek Win32 ist "voll".

Ich habe packe im Moment die Ordner in die Umgebungsvariable PATH, also den globalen Suchpfad. Aber dessen Länge ist wohl begrenzt (4096?).
Jetzt habe ich eine Umgebungsvariable Suche1, packe dort die folgenden Pfade rein und binde diese unter Tools/Optionen/ Bibo Win32/Suchpad mit $(Suche1) ein.
Mittlerweise bin ich bei Suche2 ...

Verwende nicht den globalen search path oder die PATH-Variable, sondern die äquivalenten Pfadangaben in den Projekt-Options. Um die Pfadnamen zu verkürzen definieren in Tools-Options ein paar environment variablen mit oft vorkommenden Pfadelementen, die kann man dann in den Projekt options per $(name) in den Pfadnamen verwenden.

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1425340)

Weil Delphi immer alle Units aufmacht.

Aufmachen, im Sinne von im Editor anzeigen? Also jedenfalls nicht hier.

[hoika]

Hallo,
hm, stimmt, die geöffneten stehen in der dproj.
Nun zumindestens will ich meine dpr kurz halten.

[hoika]

Hallo,

Zitat:

Verwende nicht den globalen search path oder die PATH-Variable, sondern die äquivalenten Pfadangaben in den Projekt-Options. Um die Pfadnamen zu verkürzen definieren in Tools-Options ein paar environment variablen mit oft vorkommenden Pfadelementen, die kann man dann in den Projekt options per $(name) in den Pfadnamen verwenden.

Ah, so erfolgt die Vorbereitung der $() auch.
Damit musste ich mich noch nie beschäftigen ;)

Aber:
Das mache ich ja schon mit meiner Suche1, Suche2 nur das ich Delphi immer
nach dem Erweitern der Systemvariable neu starten musste.
Das entfällt jetzt hoffentlich.

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1425360)

hm, stimmt, die geöffneten stehen in der dproj.

Nein, die stehen in der dsk.

Zitat:

Zitat von hoika (Beitrag 1425360)

Nun zumindestens will ich meine dpr kurz halten.

Ich fürchte, damit tust du dir keinen Gefallen.

Arbeite doch probeweise mal ein paar Tage mit so einer abgespeckten dpr, bevor du dich da festlegst. Ich würde allein schon die dann fehlenden Einträge in IDE-Insight vermissen.

[hoika]

Hallo,
ich arbeite ja bereits damit ;)
Und zwar schon eine Weile.
Es kommen aber immer neue Verzeichnisse dazu,
und dann heißt es "ran an die Umgebungsvariablen".

PS:
Ich versuche gerade, unsere Konfigurationen zu vereinheitlichen,
aber ich bin der Standard ;)

PS2:
es sind etwa 2.000 Dateien, die wollt ich nicht alle in die dpr reinhaben.

[freimatz]

die dpr?
Du hast nur eine? Dann wird es vielleicht Zeit für Packages.
Wir haben ein vielfaches an Dateien wie Du und die sind nahezu alle in der jeweiigen dpr mit drin.

[Rollo62]

Ich separiere das möglichst, die MainForm lädt nur die Views per Runtime Code,
in der DPR wird quasi nur die Mainform gestartet, wo die Views reingeladen werden.

So hat jedes Unit seine Referenzen, und in der DPR ist fast nichts.
Wie schafft man es überhaupt 2000 Units in der DPR zu haben, ist das ein Konsolenprogramm :stupid:
Oder kommen die Einträge von 3rd Party Komponenten ?

[TigerLilly]

Zitat:

Zitat von Rollo62 (Beitrag 1425452)

Ich separiere das möglichst, die MainForm lädt nur die Views per Runtime Code,
in der DPR wird quasi nur die Mainform gestartet, wo die Views reingeladen werden.

So hat jedes Unit seine Referenzen, und in der DPR ist fast nichts.

Die DPR muss doch jede Unit usen, die deine Units benutzen wollen - außer jenen, die im Bibliothekspfad liegen.

Wenn der Bibliothkspfad keine projektspezifischen Units enthält, kommen in der DPR rasch einige Dateien zusammen.

[hoika]

Hallo,

Zitat:

Die DPR muss doch jede Unit usen, die deine Units benutzen wollen

Eben nicht, warum soll ich alle 2.000 Units dort eintragen.
Wenn Unit25 in Unit22 benutzt wird und Unit22 in Unit4, und Unit4 in Unit_FrmMain
warum sollen alle UnitsX in die DPR und nicht nur Unit_FrmMain?

[TigerLilly]

Weil der Compiler den Pfad nicht auflösen kann. Entweder DPR oder Bibliothekspfad.

DPR

Delphi-Quellcode:

program Main;

uses
  SysUtils,
  uSingleInstance,
  uPath,
  Forms,
  fNUTSMain in 'Forms\fNUTSMain.pas' {frmNUTSMain},
  cNUTSMain in 'Forms\cNUTSMain.pas',
  uNUTSConstants in 'Constants\uNUTSConstants.pas',
....

vs Unit:

Delphi-Quellcode:

unit uDaten;

interface

uses
  Classes, uLMDaten, uBaseXMLDBDaten;
..

[Rollo62]

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

[TigerLilly]

Aber da geht es nicht um das Erzeugen der Forms, die kämen uU noch dazu, wenn das wer so macht.

Hier geht es nur darum, ob die benutzen Units über die DPR (=einzeln auflisten) oder über den Bibliothekspfad (= NoGo für Projektdateien) gefunden werden.

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