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.