Suchpfade von Delphi ?

[jaenicke]

Es gibt den Bibliothekspfad. In dem schaut der Compiler nach um die Units zu finden, die in dem Projekt benutzt werden. Die werden dann zum Kompilieren und Linken benutzt.

Deshalb gehören in den Bibliothekspfad die Verzeichnisse, in denen die kompilierten Versionen der Units liegen, damit die einfach nur gelinkt und nicht unbedingt kompiliert werden müssen.

Der Suchpfad dagegen ist der Pfad, in dem der Debugger zusätzlich zum Bibliothekspfad nach den Quelltextdateien der Units sucht. Das heißt, wenn du z.B. in eine Prozedur hineinsteppst, wird dort nach dem Quelltext dazu gesucht.

Dann gibt es dazu die Debugversion z.B. des Bibliothekspfads, in denen die kompilierten Versionen der Units inkl. Debuginformationen gesucht werden.

[Stevie]

Dazu gabs neulich auch schon ein QC Eintrag. Ich kann nur empfehlen, die IDE auf englisch umzustellen, hier haben sich nämlich 2 fiese und irreführende Übersetzungsfehler eingeschlichen.

Einmal gibt es in den Environment Options\Delphi Options\Library den Browsing path (mit Suchpfad übersetzt). Das ist der Pfad, wo die IDE die Source Dateien suchst, wenn du Ctrl+Enter auf die Units machst (oder Strg+Click). Außerdem gibt es dort den Library Path. Dort sucht Delphi dcu und pas Dateien für das Kompilieren.

In den Projekt Optionen gibt den Search path (Übersetzung: Suchpfad). Das ist eigentlich das gleiche wie der Library Path aus den Environment Optionen. Das sieht man auch sehr gut, denn dort stehen die Pfade aus dem Library path der Environment Options drin. Zusätzlich dazu kannst du dort für das Projekt noch Pfade hinzufügen.

Beim Schreiben ist mir aufgefallen, dass auch die englische Version etwas verwirren kann - aber ich finde weniger, als 2mal das gleiche Wort zu haben, was aber unterschiedliche Bedeutungen hat.

Übrigens ist es megaätzend, dass sie die Build Konfigurationen lokalisiert haben... hatte neulich plötzlich nen Débogage Verzeichnis, weil das in nem 3rd Party Package so drin stand

[stahli]

... jetzt mal Fragen zu XE3

Ich habe eine Projektgruppe
-Exe1
-Exe2
-Exe3
-Package

Package wird von 2 Exen genutzt.

Alle kann ich als Debug- oder Release-Version kompilieren.

Was soll ich aber in den Umgebungsoptionen für Pfade einstellen?
Die DCU´s gibt es ja jeweils in zwei Zielordnern.

Wenn ich Exe1 als Debug-Version erstelle, wie wird dann auch das Package als Debug-Version eingebunden und anders herum eben als Release?
Wird das als abhängiges Package vielleicht automatisch berücksichtigt?

[Cashew]

Ich hätte hierzu auch mal eine Frage...

Für meine Delphi 10.2.3 IDE habe ich eine zusätzliche Komponente installiert. In den IDE Optionen wurde durch den Komponenten Installer der Bibliothekpfad um das Verzeichnis erweitert in dem sich die *.dcu Dateien der installierten Komponente befinden.

In den IDE Optionen habe ich dann noch zusätzlich den Suchpfad um das Verzeichnis erweitert in dem sich die Source Code Dateien der installierten Komponente befinden. Die Änderung habe ich benötigt, damit ich über STRG+Enter (wenn der Cursor im Unit Namen platziert ist) in die entsprechende Source Code Datei springen kann.

So weit so gut...


Nun möchte ich eine Methode aus dieser Komponente debuggen und habe hierzu einen Breakpoint in der entsprechenden Unit gesetzt. Dieser wird allerding ignoriert. Ich kann hier erst debuggen, wenn ich den Suchpfad des Projektes um das Verzeichnis erweitere, in dem sich die Sourcen der Komponente befinden.

Ist das normal?

[Delphi.Narium]

Nimm die zu debuggenden Datei(en) doch einfach ins Projekt auf. Dann musst Du nicht an die Pfade und die IDE weiß garantiert, um welche Datei es sich konkret handelt.

[jaenicke]

Ja, es ist normal, dass das funktioniert, wenn du den Suchpfad des Projekts ergänzt. Das liegt daran, dass dort die Bezeichnung irreführend ist. Das ist in Wirklichkeit das projektbezogene Äquivalent zum Bibliothekspfad. Einen projektbezogenen Suchpfad gibt es gar nicht.

Wenn die Komponente in ihrem Bibliothekspfad keine Version mit Debuginformationen hat, bleibt dir auch nichts anderes übrig als diesen Weg zu gehen oder die Units in das Projekt einzubinden. In jedem Fall solltest du nach dem Debuggen das DCU-Ausgabeverzeichnis deines Projekts bereinigen, damit dir die dort befindlichen DCUs der Komponente später nicht in die Quere kommen.

[Cashew]

Vielen Dank für die Antworten...

Zitat von jaenicke:

Wenn die Komponente in ihrem Bibliothekspfad keine Version mit Debuginformationen hat, bleibt dir auch nichts anderes übrig als diesen Weg zu gehen oder die Units in das Projekt einzubinden.

Wie kann man prüfen ob die Komponente über Debuginformationen verfügt?

Zitat von jaenicke:

In jedem Fall solltest du nach dem Debuggen das DCU-Ausgabeverzeichnis deines Projekts bereinigen, damit dir die dort befindlichen DCUs der Komponente später nicht in die Quere kommen.

Das könnte man doch einfach über die Debug und Release Konfiguration des Projektes lösen... Im Debug Projekt den Suchpfad (Bibliothekspfad) erweitern und in der Release Konfiguration eben nicht?!

[peterbelow]

Zitat von stahli:

... jetzt mal Fragen zu XE3

Ich habe eine Projektgruppe
-Exe1
-Exe2
-Exe3
-Package

Package wird von 2 Exen genutzt.

Alle kann ich als Debug- oder Release-Version kompilieren.

Was soll ich aber in den Umgebungsoptionen für Pfade einstellen?
Die DCU´s gibt es ja jeweils in zwei Zielordnern.

Wenn ich Exe1 als Debug-Version erstelle, wie wird dann auch das Package als Debug-Version eingebunden und anders herum eben als Release?
Wird das als abhängiges Package vielleicht automatisch berücksichtigt?

Zuerst einmal solltest Du in den Pfadoptionen für die Projekte (falls Du das noch nicht machst) für den Ausgabepfad für Units sowas wie

.\bin\$(Platform)\$(Config)

verwenden (in der Basiskonfiguration) und das auch in den Suchpfad aufnehmen. Damit erzeugt die IDE automatisch separate Unterverzeichnisse für die diversen Konfigurationen.

In deinem Beispiel sind aber die Package und die EXEs unabhaängig voneinander was die Konfigurationen angeht. Das Interface einer Package ist ja immer gleich, egal ob die Package nun mit oder ohne Debug-Infos gebaut wurde. Durch die Angabe von Abhängigkeiten für die Projekte in der Gruppe kannst Du zwar die Reihenfolge beeinflussen, in der die Projekte gebaut werden, wenn Du die ganze Gruppe bauen läßt, aber für jedes Projekt wird dessen aktive Konfiguration gebaut. Es gibt meines Wissens keine Möglichkeit, für eine bestimmte Konfiguration eines Projektes eine Abhängigkeit von einer bestimmten Konfiguration eines anderen Projektes zu definieren.

Was Du aber machen kannst ist einfach zwei Projektgruppen mit den gleichen Projekten zu erstellen, eine mit der Debug-Konfiguration für alle Projekte aktiviert, eine mit der Release-Konfiguration für alle Projekte.

[Ghostwalker]

Zitat von jaenicke:

Es gibt den Bibliothekspfad. In dem schaut der Compiler nach um die Units zu finden, die in dem Projekt benutzt werden. Die werden dann zum Kompilieren und Linken benutzt.

Deshalb gehören in den Bibliothekspfad die Verzeichnisse, in denen die kompilierten Versionen der Units liegen, damit die einfach nur gelinkt und nicht unbedingt kompiliert werden müssen.

Der Suchpfad dagegen ist der Pfad, in dem der Debugger zusätzlich zum Bibliothekspfad nach den Quelltextdateien der Units sucht. Das heißt, wenn du z.B. in eine Prozedur hineinsteppst, wird dort nach dem Quelltext dazu gesucht.

Dann gibt es dazu die Debugversion z.B. des Bibliothekspfads, in denen die kompilierten Versionen der Units inkl. Debuginformationen gesucht werden.

Also, wenn ich das jetzt richtig verstehe, wird im Bibleothekspfad nach DCU's gesucht und im Suchpfad nach PAS, wobei der Projektspezifische Suchpfad eigentlich ein Bibleothekspfad ist, richtig ?

[jaenicke]

Fast, im Bibliothekspfad wird auch nach Quelltexten geschaut. Liegt dort also eine passende .pas Datei wird diese genommen und kompiliert, liegt dort nur die .dcu, wird diese in kompilierter Form benutzt.

Der globale Suchpfad ist nur für den Debugger, damit der die Quelltexte zu den Units beim Debuggen findet. Für das Kompilieren wird der nicht benötigt.