Hinzufügen von Dateien zur DPR-Datei im Vergleich zu Projektpfaden in Delphi 2010

Question

Wir migrieren gerade von D7 nach D2010 und debattieren über die Bereinigung der Projektpfade. Wir haben eine Reihe von Verzeichnissen mit einer großen Anzahl von Pas-Dateien, die in einigen Projektpfaden enthalten sind, aber nur ein paar der Dateien werden tatsächlich von einem einzelnen Projekt verwendet.

Eine Möglichkeit besteht darin, die Projektpfade komplett zu eliminieren und nur alle benutzten Dateien im dpr zu haben.

Die zweite Möglichkeit besteht darin, nur die benötigten Dateien im dpr zu behalten und Projektpfade zu den Verzeichnissen für den Rest der Dateien zu haben.

Gibt es Argumente für eine Option gegenüber der anderen?

Answer 1

Wenn Sie alle Ihre Einheiten explizit im dpr haben, wird die Kompilierungszeit, Code-Vervollständigung, Fehlereinsicht und allgemeine Navigation erheblich verbessert.
Es hindert Sie nicht daran, Ihre Dateien in Ordnern und Unterordnern zu organisieren, aber verlassen Sie sich nicht auf die verschiedenen Pfade, um sie zu finden.
Auf einem großen Projekt mit Millionen LOC, macht es einen riesigen Unterschied.

Answer 2

Ich würde dafür sprechen, alle Dateien einzuschließen, die das Projekt im Projekt selbst verwendet. Dies verbessert die Leistung der "Einblicke", indem sichergestellt wird, dass gebrauchte Einheiten Teil des Projekts sind. Darüber hinaus können Sie damit Ihren Code im Projektmanager einfacher verwalten. Große komplizierte Pfade zu haben ist fragil und kann schwer zu verwalten sein.

Answer 3

Die Kommentare über die Beschleunigung von Einsichten haben mich fasziniert und ich werde es versuchen, aber bis jetzt habe ich nie gemeinsame Einheiten in die Projekte aufgenommen, die sie benutzten. Stattdessen habe ich Pakete für jede Bibliothek erstellt und sie der Projektgruppe hinzugefügt (meistens nur für organisatorische Zwecke, d. H. Ich kompiliere sie nie als Laufzeitpakete). Ich fand das einfacher zu verwalten (besonders mit all den letzten Verbesserungen im Projektmanager), als alle Dateien in einem Projekt zu haben, da die Ordnerhierarchien innerhalb der einzelnen (Paket-) Projekte nicht so tief sind und besonders keine ".. "-Ebene auf diese Weise.

Answer 4

Gründe für die nicht alle Dateien im Projekt gehört:

• weniger Zeit, um ein Projekt (Formulare und Datamodules benötigen zusätzliche Zeit)
• schnelle Datei Refactorings (Umbenennung/Verschieben von Dateien und Verzeichnissen zu öffnen/schließen erfordert nicht alle Projekte)
• leichter bearbeiten, um die Einheiten zu finden, die die Kernanforderungen und der Einstiegspunkt Position für die Anwendungslogik sind (uses MyInterfaces, MyTypes, MymMainUnit;)

Und dieser QC-Eintrag:

Bericht Nr: 77687 (RAID: 273.031)
Status: Offen Schnitt in der.dpr Quelle wird langsamer mit mehr Einheiten in dem Projekt http://qc.embarcadero.com/wc/qcmain.aspx?d=77687

Update: Jetzt weiß ich, dass es viele Möglichkeiten, um die Projektdatei zu öffnen :) - Aber mein Punkt ist, dass in einer dpr mit 500 Unit-Referenzen Es ist schwierig, die "wichtigen" (oder "wichtigsten") Einheiten zu finden, die den Ausgangspunkt für einen Drilldown in die Quelle darstellen. Es ist einfacher, Code zu untersuchen, wenn es sich um eine "leichte" Projektdatei handelt, die nur die notwendige Einheitenreferenzen.

Answer 5

Ich bin dafür, "Bibliothekseinheiten" von "Projekteinheiten" zu trennen und alle "Bibliothekseinheiten" im Suchpfad zu behalten, mit allen "Projekteinheiten" in der Projektdatei. Hier sind warum:

Unsere Line-of-Business-Projekte sind große, fast Millionen-LOC Art von Projekten, aber neben diesen gibt es buchstäblich Hunderte von kleineren Projekten für allerlei kleine Dinge. Wenn die "Bibliothekseinheiten" auf dem Suchpfad verfügbar sind, ist es sehr einfach, diese Einheiten einfach zu verwenden, ohne sie dem Projekt hinzuzufügen: Ein Schritt weniger, der summiert!

Die Verwendung des Suchpfads erleichtert das Verschieben von PAS-Dateien. Dies ist mir wichtig, da ich gerade dabei bin, unsere gesamte "Build-Umgebung" neu zu organisieren, um Versionskontrollsysteme besser zu nutzen.

Wenn Sie eine der gemeinsam genutzten Einheiten ändern und sie abhängig von einer anderen gemeinsam genutzten Einheit wird, müssen Sie nicht viele Projekte aktualisieren, sie funktionieren einfach.

Ich würde nie in Erwägung ziehen, Komponenten von Drittanbietern (oder VCL-Komponenten) zu meinem Projekt hinzuzufügen. Warum also meine "Bibliothekseinheiten" zum Projekt hinzufügen? Wir müssen irgendwo die Grenze ziehen, denn wenn wir dem Projekt absolut alle Dateien hinzufügen würden, in der Hoffnung auf schnellere Kompilierungszeiten, würden wir unhandlich große Projekte haben!

Delphi ändert automatisch den Namen der Dateien in der DPR-Datei in relative Dateinamen. Aus diesem Grund können Sie Ihr Projekt nicht wirklich von seiner aktuellen Position aus verschieben. Versuchen Sie nun, "verzweigen" und zwei Kopien des Projekts gleichzeitig auf demselben Rechner (ein "Release" und ein "Work-in-Progress") am Leben zu erhalten. (Dies ist meine Aufgabe, meine Build-Umgebung für GIT vorzubereiten, mit dem einzigen Ziel, BRANCH zu machen).

Als Referenz sind meine "Bibliothekseinheiten" diejenigen Einheiten, die in nicht verwandten Projekten verwendet werden (denken Sie an: Komponenten und Dienstprogramme).