![]() |
Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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? |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
Hat aber Vor- und Nachteile: Wenige oder Ein Unterverzeichnis:
Viele Unter-Verzeichnisse:
|
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Hallo,
danke für die vielen Antworten, hilft mir aber in dem Fall nicht wirklich ;) Zitat:
Zitat:
PS: Prinzipiell will ich auch, dass alle Rechner die gleiche Konfiguration haben. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
|
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
|
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Hallo,
hm, stimmt, die geöffneten stehen in der dproj. Nun zumindestens will ich meine dpr kurz halten. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Hallo,
Zitat:
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
Zitat:
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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 ? |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
Wenn der Bibliothkspfad keine projektspezifischen Units enthält, kommen in der DPR rasch einige Dateien zusammen. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Hallo,
Zitat:
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? |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Weil der Compiler den Pfad nicht auflösen kann. Entweder DPR oder Bibliothekspfad.
DPR
Delphi-Quellcode:
vs Unit:
program Main;
uses SysUtils, uSingleInstance, uPath, Forms, fNUTSMain in 'Forms\fNUTSMain.pas' {frmNUTSMain}, cNUTSMain in 'Forms\cNUTSMain.pas', uNUTSConstants in 'Constants\uNUTSConstants.pas', ....
Delphi-Quellcode:
unit uDaten;
interface uses Classes, uLMDaten, uBaseXMLDBDaten; .. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Nur wen man alle Forms automatisch erzeugen lässt, das mache ich eben nicht.
|
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Hallo,
Zitat:
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
Projektspezifische Dateien: DPR |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Zitat:
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. |
AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden
Hallo,
ich finde die Diskussion hier sehr gut und produktiv! *FileMon anwerf* |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz