Unter welchen Bedingungen wird ein System-Unit Fix kompiliert und eingebunden ?

[himitsu]

1. in dem Projekt gibt es in deinem DCU-Ausgabeverzeichnis nur eine DCU der Unit A.

Wenn du in deinen USES den Unitnamen von A angibst, dann wird deine DCU benutzt,

aber, verwendest du noch andere Dateien, wo du die originale DCU von DELPHI verwendest, die in sich eine Unit A einbinden,
dann sind die ja bereits fertig kompiliert und haben daher natürlich weiterhin die originale DCU A gelinkt,
womit es dann in deiner EXE zwei Mal die A gibt.

Willst du etwas Fixen, und du bist nicht der Einzige, welcher diese Unit linkt und der Fix soll überall rein,
dann mußt du also alle Units kopieren und neu kompilieren, auch Jene, welche diese Unit ebenfalls verwenden und die auch diese verwenden usw.



Da kommt man womöglich/vermutlich mit Hooks besser, wenn man nicht der Einzige ist, der diese Unit einbindet.

[dummzeuch]

Zitat von himitsu:

aber, verwendest du noch andere Dateien, wo du die originale DCU von DELPHI verwendest, die in sich eine Unit A einbinden,
dann sind die ja bereits fertig kompiliert und haben daher natürlich weiterhin die originale DCU A gelinkt,
womit es dann in deiner EXE zwei Mal die A gibt.

Fertig compiliert <> fertig gelinkt.

Beim Compilieren entstehen DCU-Dateien. Diese nimmt dann der Linker und fügt sie zu einem Executable zusammen. Es kann immer in einem Exectuable nur eine DCU mit dem jeweiligen Unit-Namen geben.

Insofern ist sichergestellt, dass, wenn das Programm eigene (veränderte) Units verwendet, auch nur diese verwendet werden.

[Delphi.Narium]

Zitat von himitsu:

1. in dem Projekt gibt es in deinem DCU-Ausgabeverzeichnis nur eine DCU der Unit A.

Wenn du in deinen USES den Unitnamen von A angibst, dann wird deine DCU benutzt,

aber, verwendest du noch andere Dateien, wo du die originale DCU von DELPHI verwendest, die in sich eine Unit A einbinden,
dann sind die ja bereits fertig kompiliert und haben daher natürlich weiterhin die originale DCU A gelinkt,
womit es dann in deiner EXE zwei Mal die A gibt.

Willst du etwas Fixen, und du bist nicht der Einzige, welcher diese Unit linkt und der Fix soll überall rein,
dann mußt du also alle Units kopieren und neu kompilieren, auch Jene, welche diese Unit ebenfalls verwenden und die auch diese verwenden usw.



Da kommt man womöglich/vermutlich mit Hooks besser, wenn man nicht der Einzige ist, der diese Unit einbindet.

Oder der Kompiler gibt den Hinweis aus, dass Unit X mit einer anderen Version von A kompiliert wurde, und er bricht den Kompiliervorgang ab.

Zuweilen stellt Delphi von ganz alleine beim Kompilieren fest, dass es da einen Konflikt gibt und weist darauf hin.

Zumindest Delphi 7 und älter konnten sowas. Geht das heute nicht mehr?

Eigentlich ist wichtig, dass man die veränderten Sourcen ins Projekt aufnimmt und sicherstellt, dass der Kompiler nur diese und die zugehörigen DCUs finden kann.

D. H.: Die "Originale" sollten in allen Pfadangaben hinter den eigenen, veränderten Sourcen / DCUs zu finden sein (oder im Idealfall garnicht zu finden sein).

Wurde eine Unit mit Deiner veränderten FMX.ListView.pas im Uses kompiliert und Dein Projekt enthält eine weitere Unit, die mit der originalen FMX.ListView.pas im Uses kompiliert wurde, so sollte der Kompiler dies bemerken und Dich darauf hinweisen.

Im Zweifelsfalle nehme ich immer alle Units in die DPR auf, die "irgendwo" in einer Unit des Projektes per Uses aufgerufen werden und bei denen die Möglichkeit eines Konfliktes bestehen könnte. Damit habe ich bisher immer alle Konflikte auflösen können (auch wenn die DPR dadurch schonmal etwas unübersichtlich lang werden kann).

Der DCU-Ausgabepfad ist bei mir immer gesetzt, so dass die Original-DCUs eventuell neu zu kompilierender "delphieigener Units" nicht überschrieben werden.

[himitsu]

Es kommt auch drauf an, wie viel man mit Packages und DLLs arbeitet.

Bei uns wurde mal eine Unit doppelt ins System einkompiliert, mit dem Ergebnis dass ein Kollege tagelang einen Fehler suchte, wo ich am Ende den Fehler fand, dass die globale Variable auch doppelt war.
An einer Stelle gesetzt, geprüft war sie auch voll, aber von einer anderen stelle aus abgerufen war sie plötlich leer ... nochmal geprüft und die war wieder voll.

[edit]
OK, stimmt ... fast vergessen ... in einem Modul sind UnitNamen eindeutig. (EXE oder DLL, wobei BPLs als gesamtsystem zusammengehören)
Bei uns war die Unit in zwei DLLs, anstatt in einer gemeinsamen BPL.

Aber Dank Default-Namespases kann man das Problem mit der Eindeutigkeit umgehen, indem man Einen definiert und seine Unit damit erweitert.

[Rollo62]

Hallo Phillip,

das mit dem Unterverzeichnis hatte ich auch früher probiert.
Es gab aber trotzdem nicht passende Breakpoints im Projekt.

An Alle, danke für die Kommentare.
Ich sehe es ja genauso, aber es geht bei mir nicht um Dll oder Bpl.
Ich habe auch keine statischen Librries drin, alles ist möglichst mit BuildAll neu gebaut.
In der Regel mache ich auch ein Clean vorher, so das es keine DCU Leichen geben sollte.

Trotzdem sehe ich manchmal verrutschte Breakpoint.

Mir ist aber gerade eingefallen das ich doch 2-3 eigene Controls in der IDE installiert habe.
Diese könnten die Ursache sein, wenn nicht neu kompiliert ist das der Einzige gelinkte Code bei mir, der mir einfällt.
Das kann der Grund sein, kann aber gerade nicht testen.

Nochmal zu den Unterverzeichnissen, funktioniert das immer 100% sicher, denn das war vor ein paar Jahren mein erster Versuch.
Wegen Linkprobleme mit verrutschten Breakpoints bin ich aber davon abgekommen.
Können solche statischen Libraries noch an anderen Stellen auftreten ?
Wie bekommt man sowas mit, denn Warnings sehe ich nicht.

[Rollo62]

Das was Thomas zu Compiler Linker schreibt sehe ich auch so.
Was mir dazu einfällt wäre eine Sitation wo eine Optimierung z.B. die Unit in einem Unterverzeichnis nicht linkt.
Weil Compiler Linker denken die ist nicht benutzt.

Wäre sowas denkbar ?

Dann müsste man in jedem Fix eine DummyRoutine aufrufen, damit es gelinkt wird.

[dummzeuch]

Zitat von Rollo62:

Das was Thomas zu Compiler Linker schreibt sehe ich auch so.
Was mir dazu einfällt wäre eine Sitation wo eine Optimierung z.B. die Unit in einem Unterverzeichnis nicht linkt.
Weil Compiler Linker denken die ist nicht benutzt.

Wäre sowas denkbar ?

Dann müsste man in jedem Fix eine DummyRoutine aufrufen, damit es gelinkt wird.

Eigentlich nicht. Wenn der Compiler Sourcecode und DCU findet, prüft er, welches neuer ist, und compiliert dann neu. Wenn eine Unit nicht benutzt wird, spielt es keine Rolle. Wenn Du wissen willst, ob eine Unit in ein Executable eingebunden wird, kannst Du in das .MAP-File des Linkers gucken. Da steht allerdings nur der Unitname drin, nicht der komplette Dateiname. Es gibt auch die Möglichkeit zur Laufzeit die Liste der Units durchzugehen, aber auch das liefert wieder nur den Unitnamen, nicht den Dateinamen.

[himitsu]

Wenn jemand die PAS von Delphi verändert, dann passen sie natürlich nicht mehr zu den Debuginfos des Compilats und Zeilen können verrutschen.
Kann natürlich auch mal sein, dass der Hersteller bereits unpassende Dateien ausgeliefert hat.

z.B. hab ich bei mir abgestellt, dass schreibgeschützte Dateien im Editor schreibgeschützt sind, damit ich bequemer dort kopieren/ausschneiden/umformatieren/... kann, wenn ich in den Sourcen mal was suche.
Allerdings lassen sich die Dateien bei mir dennoch nicht speichern, womit ich da keine Angst haben muß, dass was verändert wird, auch wenn die blöde Recovery-Funktion echt nervt, weil sie dort ins Verzeichnis schreiben will.
Andere haben da mehr Probleme, welche auf die "schlaue" Idee kommen Delphi wo anders zu installieren, wo der Pfad nicht durch Zugriffsrechte geschützt ist.

[jziersch]

Ich weiß jetzt nicht ob dies Dein Problem löst, ich habe aber für ein ähnliches Problem einen Unit-Alias auf eine umbenannte Unit mit Erfolg eingesetzt. Dies hilft auch bei der Unit FireDAC.VCLUI.Wait welche die IDE auch zu einem FMX Projekt standhaft hinzufügt.