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

[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.

[Rollo62]

Zitat von 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.

Dankesehr für den Vorschlag, habe auch das hier von Thomas dazu gefunden.
Sowas wie "Unit-Alias" hatte ich bisher noch gar nicht auf dem Schirm, interessant.

Mit geht es insbesondere um die falsch zugeordneten Breakpoints, die mal auftreten können.
Wenn die beim Debuggen der System-Units auftreten könnte ich das ja noch verstehen,
aber beim Debuggen der gefixten Units, die ja definitiv neu kompiliert und eingebunden habe,
sollte das doch nicht passieren.
Das Seltsame ist ja das dies mal auftreten sein kann, und dann auch mal wieder weg ist.
Bisher hat es mit einen kompletten Clean des Projektes (Batch-Datei die alle Leichen entfernt, sogar die Verzerichnisse) immer geholfen.
Das trat auch immer nur selten auf, und ich konnte mir das durch Fehler im Build-Vorgang erklären.
Diesmal ist es aber hartnäckiger.
Deshalb Suche ich gerade nach den Ursachen und Möglichkeiten wie man das zweifelsfrei weg bekommt.

Ich habe als Ursache noch meine Design-Komponenten im Verdacht, die ich womöglich nochmal neu builden müsste.
Diese haben allerdings gar nichts mit FMX.ListView zu tun, aber das Problem der Verschiebung der Breakpoints könnte sich dadurch ja trotzdem darüber erklären lassen.
Das wäre meiner Meinung nach die einzige Stelle bei mir wo sowas herrühren könnte, weil ich
ansonsten Alles aus Sourcen neu kompiliere.

Das der Fehler aus den Rx10.4 Orginal-Units/statischen Libraries kommt glaube ich eher nicht,
könnte aber natürlich auch der Fall sein.
Deshalb die Frage wie man sowas exakt herausfinden könnte (Compiler/Linker geben bei mir ja keine Warnung).

Bin aber erst noch anderweitig beschäftigt, muss ich ein bischen später checken.

[Rollo62]

Ich denke Schuld and den verschobenen Breakpoints war die Design-Komponente,
welche eine gemeinsame Unit mit hauptsächlich globale Konstanten eingebunden hat.
Die Konstanten hatte ich mal ergänzt und umgebaut, aber vergessen den Design-Unit mit upzudaten.

Ich habe diese Unit jetzt neu gebuildet und installiert, die Breakpoints stimmen wieder.
Alle Fixes liegen jetzt wie bisher in der DPR, und im Verzeichnis neben der DPR.

Delphi-Quellcode:

Uses
  ...
  , FMX.ListView in '_FmxFixes\FMX.ListView.pas'
  ...
  ;

Das funktioniert soweit, so hatte ich es auch bisher.


Zum Thema Aufräumen der Units aus der DPR bin ich aber noch nicht ganz am Ziel.
Ich möchte die DPR möglichst sauber halten, aber das Zusammenfassen aller Fixes in einer Unit
z.B. FmxFixes.pas

Delphi-Quellcode:

//DPR
Uses
  ...
  , FmxFixes in '_FmxFixes\FmxFixes.pas' //<== Da kann man es genau spezifizieren
  ...
  ;

//FmxFixes.pas

Uses
  ...
  , FMX.ListView  //<== hier nicht mehr, die gefixten Units MÜSSEN wohl neben der DPR liegen
  ...
  ;

A. Das kompiliert eben leider nicht.
Wenn an anderer Stelle FMX.ListView benutzt wird, dann nimmt er das orginale System-Unit.

Ich möchte aber gerade den ganzen Müll aus der DPR entfernen, und möglichst zentral einbinden,
z.B. über FmxFixes.pas, FmxFixes.inc, o.ä.


B. Abhilfe schafft, wenn ich im Search Library als ersten Suchpfad die _FmxFixes mit angebe,
dann wird im Unterverzeichnis _FmxFixes zuerst gesucht:
  _FmxFixes\ Vergesse ich das Unterverzeichnis kompiliert es u.U. auch, aber keiner merkt es.

Kompilieren, Linken Ausführen funktioniert.

Wenn ich jetzt aber in irgendeiner anderen Unit die auch FMX.ListView benutzt (oder auch in der FmxFixes.pas selbst),
dieses File öffne (mit Ctrl-Enter oder Context-Open File at Cursor),
dann wird NICHT das gefixte, sondern das Orginal-Unit geöffnet.
Im Editor können auch mal beide FMX.ListView.pas Units geöffnet sein, was mich extrem nervt,
denn das Öffnen per IDE zeigt in der Regel immer das Falsche an.

Genauso hatte ich es damals auch mal beim Debuggen festgestelt, weshalb ich die Lösung oben mit allen Fixes neben der DPR direkt in die DPR eingebunden einsetze.
Es war für mich kein Verlass darauf von wo die IDE sich gerade die Units holt, selbst wenn das der Compiler/Linker womöglich richtig macht.
Die Gefahr in der IDE das Falsche File zu Editieren ist sehr hoch.

C. Fixes im Unterverzeichnis, aber direkt in die DPR einbinden:
Wenn ich jetzt die Fixes in den Unterveerzeichnissen angebe scheint es zu funktionieren, auch in der IDE (dankesehr nochmal an Phillip), ich werde das mal weiter beobachten.
Ich meine es gab da auch vertauschte Units beim Debuggen.
Meine Lieblingslösung wäre das aber noch nicht, weil die DPR zig Fixes enthalten muss.

Deshalb hatte ich es vor Jahren schonmal aufgegeben, ich fürchte fast ich muss den ganzen Fixes-Müll in der DPR behalten.

Es ist wirklich zu blöd das Delphi keine Verzeichnisse im Unit-Namen unterstützt, nur in der DPR.