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.