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

[Rollo62]

Hallo zusammen,

ich möchte ein System-Unit ändern, und in meiner Library neu kompilieren lassen,
möglichst so das alle statischen Verweise darauf in anderen Orginal System-Units und Libraries umgelenkt werden.

Ich nehme als Beispiel mal FMX.ListView
FMX.ListView.pas // <== dies enthält ein paar Fixes, und das möchte ich in meinem Projekt nutzen
das Unit includiert ein paar weitere Units

Delphi-Quellcode:

Uses
    ...
    , FMX.ListView.Adapters.Base
    , FMX.ListView.Appearances
    , FMX.ListView.Types.pas
    , FMX.ListView.iOS
...

Die nehme ich vorsichtshalber auch mit in mein Projekt, damit auf jden Fall alle zusammenhängenden Units neu kompiliert werden.

Wenn ich die in mein Projektverzeichnis lege, und in meine Projekt DPR einfüge

Delphi-Quellcode:

program T342_Test;

{$R *.dres}

uses
  System.StartUpCopy,
  FMX.Forms,
  UMain_Frm in 'UMain_Frm.pas' {Form_Main},
  UMain_Modules in 'UMain_Modules.pas',
  FMX.ListView in 'FMX.ListView.pas',
  FMX.ListView.Types in 'FMX.ListView.Types.pas',
  FMX.ListView.iOS in 'FMX.ListView.iOS.pas',
  FMX.ListView.Adapters.Base in 'FMX.ListView.Adapters.Base.pas',
  FMX.ListView.Appearances in 'FMX.ListView.Appearances.pas';

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm_Main, Form_Main);
  Application.Run;
end.

.. dann scheint es zu funktionieren wie gewünscht.
Der Debugger kann die DCU-Units richtig zuordnen, die Debug-Breaks scheinen zu stimmen.

D.h. ich vermute das die neu kompilierten Units auch korrekt in meinem Projekt angemommen sind.

Erste Frage:
Wie kann ich sicher sein das nicht ein anderes System-Unit noch die Orginale Unit benutzt,
und ich zwei "DCU-Versionen" in mein Projekt einbinde ?


Ich würde dieses Chaos in der DPR gerne aufräumen, und leider erlaubt die IDE/Compiler keine Unterverzeichnisse an bestimmten Stellen.
Deshalb mache ich das sicherheitshalber immer so wie oben.

Meine zweite Frage ist,
wie könnte ich diese Fixes besser zusammenfassen ?,
am Besten so das ich nicht alle Units (keine) in der DPR auflisten muss.


A.) Meine Versuche das in Unterverzeichnisse zu legen funktioniert anscheinend nicht zuverlässig
Project\TestProject.dpr
Project\Fixes\FMX.ListView.pas
...


B. Meine Versuche nur eine zentrale Fixes.pas Unit in das Projektverzeichnis zu legen funktioniert anscheinend auch nicht sicher.
Project\TestProject.dpr
Project\Fixes.pas //<=============
Project\Fixes\FMX.ListView.pas
...

mit der zentralen Unit in der DPR

Delphi-Quellcode:

unit Fixes;

interface

Uses
    FMX.ListView
  , FMX.ListView.Types
...

implementation

end.

C. Ich habe auch probiert die Orginal-Units per include in Wrapper-Units zu laden,
um so zumindest verschiedene IDE-Versionen zu kapseln, so in der Art

Delphi-Quellcode:

unit FMX.ListView;

{$IF     DEFINED( RX1040 ) }
{$I FMX.ListView_Rx1040 }
{$ELSEIF DEFINED( RX1033 ) }
{$I FMX.ListView_Rx1033 }
{$ENDIF }

Das geht wenn man in den Varianten-Units den Header weglässt, löst aber nicht mein eigentliches Problem, das ich die Files genre besser sortieren würde.

Bin ich der Einzige dem solche Chaos-Anordnungen auf die Nerven gehen,
oder hat vielleicht jemand einen guten Tipp wie man das Ganze besser, sauberer organisieren könnte ?

[himitsu]

Die werden nie neu kompiliert. Zum Kompilieren werden die DCUs verwendet und nicht die PAS, drum stehen die hauseigenen PAS auch nicht im Suchpfad für den Compiler.
Wenn, dann mußt du das selber nachen und deren DCU und Debug-DCU aktualisieren. Uns mit viel Pech auch noch die BPLs und all deren Abhängigkeiten.

Für die eigene Verwendung kann man die Suchpfade so anpassen, dass die eigene Datei vor denen des Delphi gefunden werden.
Aber das ersetzt nur dort wo kompiliert wurde, also z.B. nicht:

• du erstellst dir eine System.Classes.pas und die steht im Suchpfad weiter vorne
  • alternativ kann man in der DPR diese Unit aufnehmen, bzw. im Projektmanager,
    wo die Unit dann inkl. Pfad direkt gewählt wird
• dann wird in den USES von dir die neue Datei benutzt
• aber wenn du nicht auch die System.Forms.pas kopiert hast, dann verwendet deren Kompilat natürlich weiterhin die originale Classes

[Rollo62]

Zitat von himitsu:

Die werden nie neu kompiliert.

Ja richtig, das meinte ich auch nicht (hab mal den Titel angepasst um das besser zu beschreiben).

Sagen wir mal es gibt eine Orginal-DCU der FMX.ListView.pas welche normalerweise statisch gelinkt wird.
Binde ich jetzt meine gefixte FMX.ListView.pas in meine Projekt-DPR ein, dann wird diese neu-kompilierte-DCU zum Projekt gelinkt, statt der statischen Orginal-DCU.
Durch den gleichen Namen der FMX.ListView.pas sollte gewährleistet sein das es im Projekt nur EINE Version der FMX.ListView-DCU geben kann (also in dem Fall nur meine, gefixte Version).

Soweit so gut.

1. Frage:
Ist das so, oder könnten auch 2 FMX.ListView-DCU's (alt/neu) gleichzeitig in einem Projekt existieren ?
Wenn z.B. andere Orginal-DCU's statisch die alte Orginal-DCU einbinden.
Wie kann ich sicher sein das wirklich nur die gefixte DCU gelinkt ist.

Leider scheint das nicht immer zu funktionieren wenn der Suchpfad nicht im .DPROJ Haupt-Verzeichnis liegt.
Dann habe ich keine Chance den Pfad zu meiner gefixten FMX.ListView.pas anzugeben, und es wird
doch die orginale DCU, oder noch schlimmer beide Versionen gelinkt.
Das könnte sich durch nicht mehr passende Breakpoints zeigen (die blauen Break-Punkte sind verschoben).

Gibt es noch andere Methoden um solche "verschobenen" Breakpoints, und falsche statische Links zu finden und zu Vermeiden ?

2. Frage:
Ich kenne nur die obige Methode (in jedem .DPROJ Hauptverzeichnis) um sicher solche Fixes zu linken und einzubauen.
Ich hoffe aber das es doch irgendeine Möglichkeit gibt diese gefixten FMX.ListView.pas irgendwo in Unterverzeichnisse zusammenzufassen, so dass sie noch sicher gelinkt werden.

Z.B. wäre auch denkbar alle diese Fixes in einem zentralen DCP/LIB zu linken,
und dann den Projekten nur die eine DCP hinzuzulinken.
Ich vermeide aber möglichst solches vorkompiliertes, statisches Linken, weil das oft mehr Probleme bringt als löst (man vergisst gerne solche statischen DCP/LIB zu aktualisieren).

Mein Favorit sind aber leichtgewichtige Units, die immer neu kompiliert werden, statt schwerer, statischen DCP/LIB Files, welche nicht immer neu kompiliert werden.
Mit Kompilierzeiten habe ich weniger ein Problem, so dass ich keine Precompiled-Libraries brauche.

[philipp.hofmann]

Der Pfad in deiner Projektdatei ist falsch bzw. zeigt nur auf das Hauptverzeichnis. Wenn Du die Datei in

Project\Fixes\FMX.ListView.pas liegen hast, muss es
FMX.ListView in 'Fixes\FMX.ListView.pas', heißen.

Ansonsten sehe ich keinen Grund, warum hier irgendetwas nicht funktionieren sollte und solche Fixes habe ich immer eingebunden. Meist sogar abhängig vom OS und der Delphi-Version:

Delphi-Quellcode:

  {$IFDEF ANDROID}
    {$IFDEF VER330}
      FMX.Media.Android in 'utils\10.3\FMX.Media.Android.pas',
      System.Android.Bluetooth in 'utils\10.3\System.Android.Bluetooth.pas',
    {$ENDIF}
  {$ENDIF}

Dabei ist wichtig, dass man diese OS-abhängigen Überschreibungen irgendwo nochmals sichert (ich führe sie in der Projekt-Datei zweimal auf, einmal auskommentiert und einmal einkommentiert, weil der einkommentierte Teil beim Umschalten zwischen den OS oftmals kaputt gemacht wird.

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