Zusätzlich zu den verwendeten
bpl gibt es noch versteckte
BPL Abhängigkeiten. Das führt dazu, dass ein Delphiprogramm noch eine Reihe
bpl beim Start verlangt,
die im Programm selbst garnicht verwendet werden.
..zumindest nicht direkt.
In meinem Projekt waren das so um die 70 bis 80
bpl, die zusätzlich mitgeliefert werden mussten.
Fehlende oder geänderte
bpl merkt man erst beim Kunden, da hier erst die isolierte Umgebung vorhanden ist.
Also vor der Auslieferung in einer delphifreien VM testen, ob das Programm startet.
Oder man schaut nach dem Compilieren mal unter
Projekt - Info auf die Liste "Verwendete Packages".
Dann beten, das kein weiteres Delphiprogramm auf dem gleichen Rechner
bpl benötigt. Das muss nicht mal mit unterschiedlichen Delphi-Versionen compiliert sein.
Grundsätzlich sollten BPLs, die mit unterschiedlichen Delphi-Versionen compiliert sind, auch unterschiedliche Namen haben. Ansonsten könnte man ja auch nicht verschiedene Delphi-Versionen gleichzeitig auf dem Rechner haben. Wer es dann ganz ordentlich machen will, gibt der
BPL dann auch noch die eigene Versionsnnummer im Dateinamen mit. Bei neueren Delphi-Versionen helfen da die Einträge für LIB-Suffix und LIB-Version. Im Zweifelsfall packt man die benötigten Packages in das Verzeichnis, wo auch die EXE liegt.
Das
bpl Konzept ist antiquiert und verursacht nur Ärger.
Wenn wirklich Modular, dann entweder
dll und Interface oder
Com-Technologie.
DLLs sind sicher nicht besser als BPLs was unterschiedliche Versionen auf dem Rechner betrifft. Und
COM unter OSX könnte auch etwas haarig werden. Delphi-Packages funktionieren aber unter allen Zielplattformen. Antiquiert im Sinne von "gibt es schon sehr lange" - ja, aber immerhin nutzt .NET dieses Konzept ja ziemlich intensiv.
Eine große Exe und Schluss oder eine kleine Exe und 80 bis 90
bpl die versioniert überwacht und updatet werden müssen, was ist besser?
Ich habe runtime
bpl zwischenzeitlich aus allen Projekten wieder herausgeworfen, da Nutzen und zusätzlicher Aufwand in keinem Verhältnis stehen.
Wie jede Technologie muss man wissen was man tut und Aufwand und Nutzen gegeneinander abwägen. Es ist sicher kein brauchbarer Weg um die EXE-Größe zu verkleinern oder den Update-Aufwand zu minimieren. Wenn es aber wie in diesem Fall um
visual inheritance geht, sind dynamische Packages ein durchaus gangbarerer Weg. Mit anderen Ansätzen wird die Lösung sicher nicht leichter.
Es gibt übrigens noch ein anderes Beispiel, wo das
Package-Konzept erfolgreich für einen modularen, dynamischen Aufbau verwendet wird: FinalBuilder!