Sollte "Library path" auf die Quelldateien von Paketen zeigen?

Das OP sagte in einem Kommentar:

  

Wenn Sie NICHT den Pfad zu Ihren Paketen im "Bibliothekspfad" hinzufügen, müssen Sie jedes Mal, wenn Sie ein neues DPR-Projekt erstellen, den Pfad zu Ihren Paketen (viele) manuell erfassen und eingeben in die Option "Durchsuchen" des Projekts, andernfalls wird "Datei xxx.dcu nicht gefunden"

angezeigt

Nicht wirklich. Sie müssen eine Standard-Projektoption erstellen. Um das zu tun, laden Sie Delphi (ich spreche hier von D2010, aber die gleiche Funktion ist zumindest in D7 verfügbar) und stellen Sie sicher, dass in der IDE kein Projekt geladen ist.

Öffnen Sie danach eine Datei (eine beliebige Datei) und gehen Sie zu Projekt / Standardoptionen / Delphi (oder C ++ Builder, Sie haben die Wahl der Persönlichkeit). Dadurch wird ein Basisbildschirm für Projektoptionen geöffnet. Konfigurieren Sie es, bis Sie zufrieden sind und drücken Sie OK.

Erstellen Sie ein neues Projekt mit "Datei / Neu / VCL-Formularanwendung" und sehen Sie, wie Ihre Standardeinstellungen angewendet werden.

BEARBEITEN: Seit XE2 wurde das Standardprojekt durch die Optionssätze .

Hilfe-Links: Siehe Ссылка Ссылка

_Creating, _Applying, _Editing, _and_Deleting - Weitere Informationen finden Sie unter: Ссылка

Wo Sie hindeuten, ist Ihr Bibliothekspfad nicht halb so wichtig wie die Ausgangspfade für die kompilierten Dateien, sowohl für dcu / dcp-Dateien als auch für exe / bpl-Dateien.

Jedes Projekt sollte eigene Ausgabepfade haben . Wenn Sie dies tun, befinden sich die Binärdateien selbst dann, wenn Sie den Bibliothekspfad auf die Quelldateien verweisen, in einem projektspezifischen Ordner und können daher niemals in andere Projekte eingreifen.

Achten Sie darauf, den globalen Bibliothekspfad (Umgebungsoptionen) zu verwenden. Meins ist eigentlich völlig leer . Nicht einmal die Standard-Delphi-Ordner wie $ (BDS) \ Lib sind dort. Warum? Weil es sicherstellt, dass jedes Projekt seine Abhängigkeiten von Bibliotheken explizit im dproj machen muss. Das bedeutet, dass Sie Projekte laden und erstellen können, die verschiedene Versionen derselben Bibliothek benötigen, ohne dass Fehler auftreten, da Ihre Umgebungspfade auf eine andere Version der Bibliothek verweisen als auf die Version, die Ihr Projekt benötigt. Das hilft auch beim Debuggen sehr, da der Debugger immer die Version verwendet, die das Projekt benötigt, anstatt auf den Pfad der globalen Umgebung zu zeigen.

Wenn eine Ihrer Bibliotheken visuelle Komponenten enthält, benötigen Sie diese immer noch nicht in den globalen Umgebungspfaden . Sie müssen nur sicherstellen, dass die IDE die BPLs von der Version verwendet, die Sie am häufigsten verwenden. Es spielt keine Rolle, ob das ein altes ist oder nicht (abgesehen davon, dass es Änderungen am Inhalt von dfm verursachen kann, aber Versionskontrolle sollte dabei helfen). Sie benötigen die BPLs nur in der IDE, damit sie beim Laden eines Formulars nicht blockiert werden. Tatsächlich haben meine IDEs normalerweise keine Komponenten von Drittanbietern installiert (obwohl die Projekte sie verwenden), aber dann mache ich nicht viel dfm und wenn ich Code in der pas-Datei eines Formulars ändern muss, sage ich es der IDE Ignoriere alle Fehler (behalte aber die Referenzen! in der Einheit des Formulars) und setze alle Änderungen an den DFM's beim Abschicken zurück.

Oh, und Ich kompiliere immer von der Quelle . Auf diese Weise muss ich, wenn ich einen Patch für eine einzelne Datei in einer Bibliothek erhalte, nicht den gesamten Installationsprozess durchlaufen, ich muss die Komponentenpakete nicht erneut kompilieren. Ich kann einfach die aktualisierte Quelldatei in den richtigen Ordner legen und weitermachen, als wäre nichts passiert.

Auch Ich verwende relative Pfade in allen meinen Projekten. Ich weiß, dass einige Leute darunter gelitten haben, aber ich habe noch nie ein Problem festgestellt. Möglicherweise, weil ich nie irgendwelche Dateien öffne, indem ich doppelt im Windows Explorer klicke, aber immer innerhalb der IDE oder möglicherweise per Drag-and-Drop aus dem Explorer, um eine (frühere Version von) Datei anzusehen, ohne sie Teil eines Projekts zu machen. Relative Pfade machen das Laden und Laden einfacher, um Kopien eines Projekts zu erstellen, haben eine beliebige Anzahl von Arbeitsbereichen (Perforce) und wechseln zwischen diesen, ohne die Pfade im dpr zu "reparieren".

All dies sind Praktiken, die ich bei der Arbeit mit vielen verschiedenen Projekten aufgegriffen habe und regelmäßig zwischen den Versionen unseres eigenen Codes hin- und herwechseln muss, was häufig auch den Wechsel zwischen den Versionen der Bibliothek mit sich bringt.

Ich schlage vor, den "globalen" Bibliothekspfad zu verwenden, um nur auf Ihre "globalen" Bibliotheken zu zeigen. Wenn .dcu vor .pas gefunden wird, werden sie ohne Neukompilierung des Quellcodes verwendet. Wenn Sie Ihren Bibliotheks-Quellcode nicht oft ändern, würde ich das vermeiden und würde ihn nicht mit anwendungsspezifischem Code "verschmutzen". IMHO-anwendungsspezifisches dcu sollte nicht in den "globalen" Bibliothekspfad gesetzt werden. Sie können das "Unit output directory" einfach verwenden, um dcu in einem gemeinsamen Verzeichnis pro Anwendung zu speichern

Die Technik, die ich unten beschreibe, funktioniert gut für uns, denn für jede Version von Delphi, die wir verwenden, verwenden alle Projekte die gleiche Version von Bibliotheken.

Zum Beispiel haben wir einen Zweig, der mit Delphi 6 erstellt wurde (und immer noch aktiv entwickelt wurde). Unser Stamm wurde vor einem Jahr nach Delphi 2009 migriert, dann vor ein paar Monaten auf 2010 migriert und wird bald migriert werden zu Delphi XE. Aber alle Projekte im Stamm verwenden die gleiche Version von Delphi und die gleiche Version unserer Bibliotheken.

Hersteller von Drittanbieterkomponenten installieren die Quelle an einem freigegebenen Speicherort und verwenden dann verschiedene Ausgabeordner für den kompilierten Code. Auf der anderen Seite bevorzuge ich es, für jede installierte Delphi-Version eine separate Kopie jeder Bibliothek eines Drittanbieters zu installieren. Wenn ich eine aktualisierte "Version 5.4" einer meiner Lieblingskomponentenbibliotheken installiere, möchte ich möglicherweise nicht, dass diese einzelne Installation auf jede von mir verwendete Version von Delphi angewendet wird. Daher wird jede Komponentenbibliothek separat für jede installierte Delphi-Version installiert. (Dies ist ein Problem, wenn die Bibliothek ein "typisches" Windows-Installationsprogramm verwendet, das das gleiche Produkt nicht mehrmals installieren möchte.)

Nachdem wir all das gesagt haben, zeigt unser globaler Bibliothekspfad unter Extras | Optionen auf die OUTPUT-Ordner aller Bibliotheken von Drittanbietern. Auf diese Weise ist jedes neue Projekt bereit, ohne zusätzliche Arbeit zu gehen, und das Kompilieren eines Projekts kompiliert den Standard-Bibliothekskode von Drittanbietern, der sich nicht ändert, wenn sich ein Projekt ändert.

In der seltenen Instanz, in der wir einen Patch (Quellcode-Override) für eine Bibliothek eines Drittanbieters benötigen, werden diese in einen separaten Ordner geschrieben und jedes Mal kompiliert, wenn das Projekt kompiliert wird. Sobald der Drittanbieter ein Update mit dem Fix veröffentlicht, entfernen wir unsere Kopie des Patches.

Wir verwenden Bibliotheken von Drittanbietern, die viel Quellcode enthalten, wie beispielsweise ReportBuilder, Raize-Komponenten, die TurboPower-Produkte usw. Ich sehe keinen Grund, den gesamten Code neu zu kompilieren, wenn ich mein Projekt "baue" / p>     

Ich sage nein, weil es schneller ist, die Anwendung zu kompilieren, da die dcus bereits kompiliert sind.