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

[Rollo62]

Zitat von Delphi.Narium:

Ehrlichgesagt verstehe ich nicht, wieso Units, die in ein Projekt aufgenommen werden und dadurch in der DPR stehen, Müll sein sollen.

Ganz einfach, da habe ich mehrere Gründe:

1. Weil das Verwalten der Fixes für mich unnützer Ballast ist.
Den bearbeite ich normalerweise nur einmal (pro Version), im Idealfall,
und will den dann komplett vergessen.
So muss ich aber in jedem Projekt, und bei jedem Update (wo ich .DPROJ neu anlegen muss,
diesen ganzen Kram wieder händisch anfassen.
Gut, die manuelle Kontrolle hat auch ihre Vorteile, aber das Copy-Paste bringt mehr Nachteile.

2. Mit "Müll" meine ich das in der .DPR ohne Fixes stehen bei mir ca. 4-5 Units pro Projekt.
Je nachdem welche Features ich nutze bekommen ich aber 5-20 Fixes-"Müll" mit da rein.
Das gleiche gilt für das Hauptverzeichnis der Projekte.
Weil ich die Fixes anscheinend nur da reinkopieren kann, damit Compiler/Linker/IDE/Debugger damit klarkommen, kommt auch dort ungewünschter "Müll" rein.
Sonste hätte ich dort ca. 10 Files pro Projekt.
Erschwerend kommt da hinzu das ich viele Mobile-Projekte habe, und dort oft .DPROJ neu anlegen muss,
damit neue Features übernommen werden.
Früher reichte eine .DPROJ bei mir auch mehrere Jahre, unter Windows, die Zeiten sind vorbei.

3. Ich benutze gerne immer gleiche, funktionierende Konfigurationen, wo die Fixes eben gut
aufeinander abgestimmt sind.
Durch den "Müll" im Projekt ist es aber kaum wartbar.
Ich mache es im Moment so das ich die benötigten Fixes ausserhalb manage, und dann den Projekten nur die funktionierenden Kombinationen einspiele.


4. Weil ich gerne die ganzen Features und Fixes global steuern und konfigurieren möchte.
Also in der Art:
Projekt braucht FMX.ListView, Projekt braucht MapView, etc. dann nur die nötigen Fixes reinbauen.
Falls eben möglich benutze ich dafür solche Defines, um Features einfach und gut verständlich ein/ausschalten kann:

Delphi-Quellcode:

{$DEFINE _X_HAS_FEATURE_NOTIFICATION_LOCAL }
{$DEFINE ___HAS_FEATURE_NOTIFICATION_REMOTE }
{$DEFINE _X_HAS_FEATURE_TTS_SPEAK}
{$DEFINE _X_HAS_FEATURE_MEDIA_AUDIO_PLAY }
{$DEFINE ___HAS_FEATURE_MEDIA_AUDIO_RECORD }
{$DEFINE ___HAS_FEATURE_WIFI }
{$DEFINE ___HAS_FEATURE_WIFI_NETWORK_INFO }  // Allow the retrieval see S4.Core.Net.Ssid.iOS

Dadurch können sich meine Module voll-automatisch richtig konfigirieren,
nur eben der "Müll" in der .DPR bleibt reine Handarbeit.
Die Gefahr ist, das man was vergisst, und dann gibt es nicht immer eine klare Fehlermeldung.
Die App crasht vielleicht weil irgend ein Fix vergessen wurde, oder veraltet ist.

5. Weil Fixes auch ständig upgedatet werden müssen, muss ich dann zig Kopien, in zig. Projekten updaten.
Ich habe mir dafür ein Kopier-System gebaut, so dass ich aus einem Fixes-Master die aktuellen Fixes in jedes Projekt updaten kann.

6. In Erweiterung zu 5.) verwaltet das dann auch verschiedene Ide-Versionen, also
Rx10.3.3, Rx.10.4.0, etc., so das jede IDE die zu ihr passenden Fixes bekommt.

Mir fallen bei längerem Nachsinnen womöglich noch mehr Gründe ein,
aber das hier reicht schon mehr als aus um mir Bauchschmerzen zu machen.


@Rolf Frei
Danke für den Vorschlag, genau das möchte ich ja machen.
Leider kommen damit z.B. Ide/Debugger nicht immer klar, wie unten beschrieben,
auch wenn Compiler/Linker etwas Lauffähiges produzieren.

Ich hatte schon oft in Sourcen gedebuggt und gesucht, nur um dann nach Stunden festzustellen das die IDE mal wieder das falsche File geladen hatte.
Deshalb kann ich die Files eben nicht in Unterverzeichnisse zusammenfassen, sondern es muss wohl Alles zusammen bei .DPR und .DPROJ im Verzeichnis liegen.
Nur dann habe ich die Gewähr das Compiler/Linker/Ide/Debugger IMMER das richtige File öffen/nutzen.

[Delphi.Narium]

@Rollo62

Ok, Dir geht es darum Redundanzen zu vermeiden.

Quasi im Idealfall: Ein Fix ist einmal ein Aufwand, für alle betroffenen Projekte gleichzeitig.

Ist er obsolte geworden, wird er genau einmal entfernt, für alle Projekte gleichzeitig.

Unter Müll verstehst Du letztlich alles das, was erforderlich ist, um Fehler in den Delphisourcen zu umgehen, vorübergehend zu beheben, bis sie im Original beseitigt worden sind.

Und ja: Es geht Dir um einen möglichst geringen Aufwand für die ganze Chose, darum, Dich um die eigentliche Entwicklungsaufgabe kümmern zu können und nicht, Dich mit nicht unerheblichem Aufwand um die "Umschiffung fremder Fehler" kümmern zu müssen und die bei der "Umschiffung" möglichen Fehler möglichst Richtung 0 zu reduzieren.

Eine absolut legitime und sinnvolle Vorgehensweise.

[Rolf Frei]

Wenn du das so machst wie ich geschrieben habe und sowohl den Library-Suchpfad als auch optional den Browse-Suchpfad mit den neuen Verzeichnis ergänzt (Globale Einstellungen: Menü Tools/Options/Language/Delphi Options/Library), sollte das problemlos funktionieren. Den Browsepfad musst du im Prinzip nicht anpassen, solange dein BUGFIX Verzeichnis die Sourcen enthält. Ich nutze das schon seit Delphi 1 so und hatte noch nie ein Problem damit.

Deine Projekte benötigen nichts eintragen! Lösche da alle deine Verküpfungen die gefixten Units und alle lokalen im Projekt herumschwirrenden DCU's. Das macht keinen Sinn, dass du das pro Projket nochmals machen willst. Die gefixten Versionen werden automtisch genutzt (kompiliert), wenn diese Pfade in den globalen Einstellungen richtig gesetzt sind und dein BUGFIX Pfad VOR den Delphi Pfaden ist.

Wenn du irgendwann mal wieder die falsche Unit angezeigt bekommst, hast du zu 100% eine Verknüpfung auf die Sourcen in deinem Projekt hinterlegt. Die Projektpfade (Projektoptionen) haben immer Vorrang vor den globalen Einstellungen und wenn du da einen Pfad auf die Originalsourcesn drin hast, ist es logisch, dass diese angezeigt werden.

[Rollo62]

Zitat von Rolf Frei:

Wenn du das so machst wie ich geschrieben habe und sowohl den Library-Suchpfad als auch optional den Browse-Suchpfad mit den neuen Verzeichnis ergänzt (Globale Einstellungen: Menü Tools/Options/Language/Delphi Options/Library), sollte das problemlos funktionieren.

Na gut, will ich dann auch nochmal mit globalen Einstellungen probieren.

Zitat von Rolf Frei:

Den Browsepfad musst du im Prinzip nicht anpassen, solange dein BUGFIX Verzeichnis die Sourcen enthält.

Das tut es, ich habe quasi nur Sourcen, und keine vorkompilierten DCU's

Zitat von Rolf Frei:

Deine Projekte benötigen nichts eintragen! Lösche da alle deine Verküpfungen die gefixten Units und alle lokalen im Projekt herumschwirrenden DCU's.

Ich habe früher auch nur Alles in den Optionen/Tools konfiguriert, bin aber seit geraumer Zeit davon ab.
Mittlerweile habe ich alle Pfade im Projekt, und in der IDE nur die Environment-Variablen.
Das ist vielleicht eine Philosophiefrage, aber so mache ich meine Projekte ziemlich autark von der benutzten IDE und Umgebung.
Damit habe ich gut Erfahrungen gemacht.

Die ganzen Fixes sind zu jedem Projekt, die Redundanz will ich reduzieren aber es kann sein das doch ein Projekt einen speziellen Fix benötigt, den ein anderes so nicht benötigt.
Das räume ich zwar ständig auf, aber die lokalen Fixes sind bei der Arbeit auch ganz praktisch,
weil ich dann immer nur im Projekt arbeite, und keinen ungeplanten Einfluss auf andere Projekte nehme.
So kann ich mehrere Projekte mit unterschiedlichen Konfigurationen nebeneinander fahren,
das wäre in der IDE mit Optionen/Pfade schwieriger zu handeln.
Die Auswirkungen der Fixes auf Mobilgeräten sind mitunter sehr mysteriös und unklar, deshalb die erhöhte Vorsicht.

Nachdem ein Fix geklärt ist kommt der in den Master, und wird er bei Bedarf in alle Projekte übernommen, oder erst Step-By-Step wenn das Verhalten noch jeweils geprüft werden muss.

Die Arbeitsweise rührt aber eher daher das ich mich eben nicht auf die IDE verlassen kann,
wie unten beschrieben.
Ich versuche Alles so einzustellen das "seltsame" Editor und Debug-Fehler gar ncht erst auftreten,
mir reichen schon die seltsamen Fehler auf den Mobilgeräten mit Permissions, Sensoren, Maps, Bluetooth, etc.

Jetzt komme ich darauf weil gerade Rx10.4 wieder etwas zickig ist, ich meine Projekte aber unbedingt bis zum 30.06. für meine Projekte lauffähig haben muss, wegen Apple's Store-Richtlinien.
Deshalb suche ich gerade ob es neue Möglichkeiten gibt die das optimieren können.
Ich sehe wieder solche "seltsamen" Effekte beim Editieren, Debuggen, etc. und habe das neue LSP und ARC im Verdacht.
Damit ich nicht nach Phantomen suche, versuche ich wenigstens die IDE-Einstellungen wasserdicht zu bekommen.

[himitsu]

Du kannst in der/den globalen Units mit {$IFNDEF XXX} bzw. {$IF not Defined(XXX)} arbeiten
und dann bei bestimmten Projekten in dessen Projekt-Optionen die Defines angeben, von dem was nicht rein soll, oder andersrum.

Alternativ geht es auch bei IncludeDateien im Quellcode.

Delphi-Quellcode:

{$DEFINE xxx}
{$INCLUDE zzz.inc}

und in der zzz.inc ein {$IFDEF xxx}

[Rolf Frei]

Rollo62, du solltest nur Sachen in das Projeket packen, die von Standard abweichen. Packe daher alles was deinem Standard entspricht in die globalen Einstellungen und mache dann nur bei den Projekten, die von deinem Standard abweichen, Einträge in den Projektoptionen. Hälst du dich da sauber dran, wirst du keine Probleme mehr haben.

[Rollo62]

@Rolf Frei

Ich nähere mich einer neuen Verson meistens behutsam, Bottom-Up, eher von den Demos her zu Projekten.
Leider muss ich hier in 10.4 meine Projekte ans Laufen bekommen, weil mir Kunden und Apple im Nacken sitzen, mit der .storyboard requirements.
Also muss ich leider den Top-Down Ansatz wählen, oder versuchen das in 10.3.3 reinzufrickeln.
Beides ist sub-optimal.

Ich habe jetzt das Ganze aber einigermaßen stabil bekommen, die groben Crashes scheinen wirklich von den zeitgesteuerten ListView Events zu kommen.
Ich sehe zwar nicht genau wo mir das ItemObjekt unter den Füssen weggezogen wird,
es ist aber sehr wahrscheinlich das dies irgendwo im Unterbau passiert.

Ich habe es jetzt so umgebaut das ich den Wert ignoriere, oder bei Bedarf den aktuellen Wert aus dem Listview nehme, und der Crash ist damit weg.

Das scheint für mich jetzt erstmal gelöst, ich bin noch am Testen,
aber die Baustelle hat nur Sommerpause, ich denke das brodelt später mal wieder hoch.

Zitat von Rolf Frei:

Hälst du dich da sauber dran, wirst du keine Probleme mehr haben.

Dein Wort in Gottes Ohr, aber hast Du auch Erfahrungen mit mobilen Plattformen gemacht ?
Da ist nichts mehr so wie es scheint, ich vermisse mein altes WinXP

[Rolf Frei]

Zitat von Rollo62:

Dein Wort in Gottes Ohr, aber hast Du auch Erfahrungen mit mobilen Plattformen gemacht ?
Da ist nichts mehr so wie es scheint, ich vermisse mein altes WinXP

Nein, Gott sei Dank nicht. Habe dafür bisher keinen Bedarf gehabt und hoffe, dass ich auch nie einen haben werde. Was hier Google und Apple veranstalten ist ja echt ne Katastrophe. Da lob ich mir mein Windows, in dem ich heute noch 20 Jahre alte Anwendungen nutzen kann.