Best Practice für Delphi Pfade gesucht

[TigerLilly]

Was gehört in welchen Pfad?

Tools/Optionen/DelphiSprache/Bibliothek

Bibliotheks(Library)pfad
Such(Browsing)pfad

Projektoptionen/Ziel
Suchpfad

In welcher Reihenfolge und wo sucht Delphi nach einer Datei und wann und wohin wird diese neu kompiliert?
In welcher Reihenfolge und wo sucht Delphi nach einer Datei wenn ich im Editor klicke?

Danke für jede Erleuchtung!

[Luckie]

Bitte gib deinem Beitrag einen aussagekräftigen Titel. "Pfade die 2te" sagt nichts über dein Anliegen aus. Du kannst den Titel bearbeiten indem du beim Beitrag bearbeiten auf "Erweitert" klickst.

[DieDolly]

Zitat:

wann und wohin wird diese neu kompiliert?

Units von Komponenten werden bei mir immer erst dann neu kompiliert, wenn ich explizit das Paket öffne, es bereinige und neu kompiliere und ggf. auch neu installiere.
DCUs und sowas landen bei meinen Komponenten im selben Ordner.

[Redeemer]

Mein Delphi kompiliert auch neu, wenn ich ein Projekt erzeuge.

DCUs wandern normalerweise da hin, wo die Sourcen liegen.

[Uwe Raabe]

Zitat von TigerLilly:

Was gehört in welchen Pfad?

Tools/Optionen/Sprache/Delphi/Bibliothek

Bibliotheks(Library)pfad: Die vorcompilierten DCUs der Libraries, die für alle Projekte gleich sind.
Such(Browsing)pfad: Die Pfade zu den Sourcen dieser Libraries, damit der Debugger die finden kann.

Ergänzend dazu:
Debug-DCU-Pfad: Die Debug-Versionen obiger DCUs.

Ebenso:
Tools/Optionen/Sprache/Delphi/Bibliothek - Übersetzt: Jeweils die sprachabhängigen Versionen davon.


Projektoptionen/Ziel
Suchpfad: Die Pfade für die Sourcen und/oder DCUs der projektspezifischen Units und/oder Libraries.

Zitat von TigerLilly:

In welcher Reihenfolge und wo sucht Delphi nach einer Datei und wann und wohin wird diese neu kompiliert?
In welcher Reihenfolge und wo sucht Delphi nach einer Datei wenn ich im Editor klicke?

Die Suchreihenfolge ist in beiden Fällen die gleiche (zumindest theoretisch). Gehört die Datei nicht direkt zum Projekt, dann hat der Projekt-Suchpfad Vorrang vor dem Bibliothekspfad. Ist die Compiler-Option "Mit Debug-DCUs" aktiv, wird der Debug-DCU-Pfad vor den Suchpfad gestellt. Gleiches gilt für die sprachabhängigen Pfade. (Achtung! Siehe dazu meine Antwort bei StackOverflow)

[TigerLilly]

An einem konkreten Beispiel (und laut gedacht):

Ich habe LibraryA.dcu. Der Pfad zu der Datei ist in Bibliotheks(Library)pfad, weil vorcompilierten DCUs der Libraries, die für alle Projekte gleich sind.

Ich habe LibraryA.pas. Der Pfad zu der Datei ist Such(Browsing)pfad,damit der Debugger die finden kann.

Wenn ich jetzt ein Build meines Projekts mache, compiliert Delphi die LibraryA und stellt die DCU in das Outputverzeichnis und nicht in den Librarypfad? Nein. Das hätte ja gar keinen Sinn. Das würde Delphi nur machen, wenn der Pfad zur PAS datei auch im Librarypfad wäre. Richtig?

Gut. Das funktioniert so für 3rd party Libs, die sich selten ändern + wenn, dann werden die gesondert kompiliert (und haben ohnedies eigene Pfadvorgaben).

Meine Projektsourcen sind über die DPR eingebunden, Kompilate landen im Output-Verzeichnis (bzw den verwandten).

Jetzt habe ich noch Code, der für mehrere Projekte gleich ist - eigener Bibliothkescode. Der soll bei Änderungen mit dem Projekt mitkompiliert werden (Halt! Schlechter Prozess? Über die versionskontrolle bekomme ich eine Änderung ausgecheckt + müsste sofort einen Buildprozess haben.) Oder ich nehme diesen Code in die DPR auf + habe halt die DCUs doppelt je Projekt.

Meinungen dazu?

[jaenicke]

Zitat von TigerLilly:

Wenn ich jetzt ein Build meines Projekts mache, compiliert Delphi die LibraryA und stellt die DCU in das Outputverzeichnis und nicht in den Librarypfad?

Nein, die Projekte finden die LibraryA.pas ja nicht, weil sie nicht im Bibliothekspfad liegt. Daher verwenden sie die vorkompilierte Version. Nur deine Packages, die die Datei eingebunden haben, legen diese in den Bibliothekspfad, der dort natürlich das DCU-Ausgabeverzeichnis sein muss.

Wir können so auch zwischen zwei komplett unterschiedlichen Umgebunden wechseln, weil ich Skripte und Programme geschrieben haben, die die Umgebung komplett umstellen mit allen Pfaden, installierten Packages usw. und auch alle Bibliotheken kompilieren.

Zitat von TigerLilly:

Jetzt habe ich noch Code, der für mehrere Projekte gleich ist - eigener Bibliothkescode. Der soll bei Änderungen mit dem Projekt mitkompiliert werden (Halt! Schlechter Prozess? Über die versionskontrolle bekomme ich eine Änderung ausgecheckt + müsste sofort einen Buildprozess haben.)

Für den Zweck gibt es bei uns teilweise gleichnamige Projekte mit _debug im Namen, die die Bibliotheksunits auch enthalten. Die werden dann verwendet, wenn die Bibliotheksunits im Rahmen des Projekts selbst angepasst werden sollen. Die haben natürlich auch ein eigenes DCU-Ausgabeverzeichnis.
Ansonsten wird solcher Code in Packages vorkompiliert und nicht in den Projekten selbst.

[TigerLilly]

Funktioniert nicht so, wie ich will.

Ich habe eine 3rdParty Lib, die hat PAS und RES Dateien im gleichen Verzeichnis und ist nach dem Setup vorkompiliert (RELEASE).
Ich habe den LibraryPfad auf das DCU Verzeichnis und auch wg der RES Dateien auf das PAS Verzeichnis.

Kompiliere ich jetzt mein Projekt mit DEBUG werden die 3rd Partys auch kompiliert. Was ich aber nicht will.

[Uwe Raabe]

Zitat von TigerLilly:

Ich habe eine 3rdParty Lib, die hat PAS und RES Dateien im gleichen Verzeichnis und ist nach dem Setup vorkompiliert (RELEASE).

Das ist leider ein häufig anzutreffender Fauxpas bei diesen Setups. Wenn man schon die Units vorkompiliert ablegt, dann müssen die Ressourcen natürlich auch als Kopie in diesem Verzeichnis abgelegt werden. Ansonsten kann man sich das vorherige Erzeugen der DCUs auch schenken.

[TigerLilly]

Ja. Und ebenso cool wäre es, wenn 3rd Party Anbieter Ihre Units in einer DPROJ oder Gruppe zusammenfassen, damit das (Neu)-Compilieren nur einen Schritt benötigt.