DLL mit FPC/Codetyphon erheblich kleiner als unter Delphi

[jaenicke]

An den Runtime Packages? Nein.

Dafür aber eben sehr viel anderes.

[Delphi-Laie]

Zitat:

Zitat von Luckie (Beitrag 1337710)

Die Runtime Packages werden standardmäßig einkompiliert. Man kann sie aber auch nicht mit eincompilieren, dann muss man die zugehörigen BPLs mit ausliefern.

Dann weiß ich, was gemeint ist, danke! Im C++-Builder (jedenfalls in den unteren / kleinen Versionen) ist es umgekehrt voreingestellt, dort muß man das explizit einstellen, daß das Compilat alles inklusiv hat, was es außer Windows noch alles benötigt.

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen. Ich kenne jemanden persönlich, der (versehentlich?) jemandem eine Arbeitsprobe - Testprogramm o.ä. - zusandte, die / das mehr als nur die Windows-Umgebung benötigte. Vermutlich ging es auch um fehlende Runtime-Packages. Kurzum, der erste Eindruck entschied ("Mist, läuft nicht"), mit der Folge, daß wegen der Verärgerung kein Auftrag zustandekam.

Also, das ist keine Alternative, sondern hat sogar die starke Tendenz zur Selbstsabotage.

[DeddyH]

Zitat:

Zitat von Delphi-Laie (Beitrag 1337731)

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen.

Wieso sollte Delphi auf dem Zielrechner installiert sein? Wenn man mit Runtime-Packages kompiliert, muss man diese dann eben mitliefern. Das Dumme dabei ist, dass sie auch zur verwendeten Compiler-Version passen müssen, d.h. ein z.B. mit Delphi 7 kompiliertes Package kann auch nur in einem ebenfalls unter Delphi 7 kompilierten Programm verwendet werden.

[Delphi-Laie]

Zitat:

Zitat von DeddyH (Beitrag 1337734)

Zitat:

Zitat von Delphi-Laie (Beitrag 1337731)

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen.

Wieso sollte Delphi auf dem Zielrechner installiert sein?

Eben - viele (die meisten?), die mit Delphi erstellte Programme benutzen, sind noch lang nicht deren Programmierer.

Zitat:

Zitat von DeddyH (Beitrag 1337734)

Wenn man mit Runtime-Packages kompiliert, muss man diese dann eben mitliefern.

Nochmals eben (außer, daß Du wahrscheinlich "ohne" meintest). Nur, erstens muß man daran denken und zweitens muß die Menge der benötigten Runtime-Packes-Dateien vollständig sein. Dazu muß man einen Delphi-freien Computer haben, um das abzusichern.

Zitat:

Zitat von DeddyH (Beitrag 1337734)

Das Dumme dabei ist, dass sie auch zur verwendeten Compiler-Version passen müssen, d.h. ein z.B. mit Delphi 7 kompiliertes Package kann auch nur in einem ebenfalls unter Delphi 7 kompilierten Programm verwendet werden.

Zum dritten Male: Eben! Was schrieb ich vom Teufel und dem Beelzebub?

Außerdem wird so - bei einmaliger Compilatweitergabe - gar nichts an Speicherplatz gespart, ganz im Gegensatz, das Rumgemache mit den vielen Einzeldateien dürfte die weiterzugebende Datenmenge tendenziell eher noch aufblähen. Erst ab dem zweiten Compilat hat man ggf. etwas gespart, je mehr Compilate, umso mehr. Da lobe ich mir doch ein "natives", ohne weitere Einschränkungen (jedenfalls keine von Delphi verusachten) lauffähiges Compilat.

[hanvas]

Zitat:

Zitat von Delphi-Laie (Beitrag 1337731)

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen.

Die Möglichkeit nicht alles in ein Binary (ob DLL oder Exe) hineinzupacken und stattdessen binäre Runtime-Packages zu verwenden ist einer der letzten Gründe warum ich Delphi gegenüber FPC bevorzuge - und das hat nichts mit dem Platz zu tun, sondern eher das man auf diese Art komplexe Applikationen strukturieren kann und durch Austausch, Weglassen oder hinzufügen von Packages auf binärer Ebene (also wie eine Art Plugin) das Verhalten und die Funktionalität der Applikation verändern kann.

cu Ha-Jö

[Luckie]

Zitat:

Zitat von Delphi-Laie (Beitrag 1337731)

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen.

Wenn ich die Runtime Packages nicht mit eincompiliere, dann sollte ich auch wissen, dass ich die Zugehörigen BPLs mitliefern muss.

Zitat:

Ich kenne jemanden persönlich, der (versehentlich?) jemandem eine Arbeitsprobe - Testprogramm o.ä. - zusandte, die / das mehr als nur die Windows-Umgebung benötigte. Vermutlich ging es auch um fehlende Runtime-Packages. Kurzum, der erste Eindruck entschied ("Mist, läuft nicht"), mit der Folge, daß wegen der Verärgerung kein Auftrag zustandekam.

War wohl auch besser so. Da derjenige wohl nicht wusste, was er tut.

Zitat:

Also, das ist keine Alternative, sondern hat sogar die starke Tendenz zur Selbstsabotage.

Nicht wenn man weiß, was man tut.

Die Tuneup Utilities machen es zum Beispiel so, dass sie alle benötigten BPLs mitliefern. Und ich kann nicht sagen, dass sie sich selbst sabotiert haben.

[TRomano]

Es wird genau dann schwierig, wenn viele Delphi-Programme auf einem Rechner mit Runtime packages laufen. In einem längeren Projekt im Süddeutschen hatten wir das Problem,
da dort die verschiedensten Delphi-Programme auch mit den unterschiedlichsten Kompilaten liefen, von D7, über D2010, XE, XE5, und XE7. Hier mit Runtime packages zu arbeiten hätte einen erhöhten Administrationsaufwand erfordert. Dann lieber eine größere Exe-Datei und die Admins sind glücklich ...
Wenn ich allerdings, wie dort, viele Delphi-Programme am laufen habe und alle mit dem selben Delphi-Compiler erstellt werden kann man darüber nachdenken.
Ach nee .. wenn man seine Komponenten-Sammlungen updated und den eigenen Sourcecode gleichzeitig ändert oder nutzt neue Features der Komponenten-Sammlungen ... dann hat man ein Problem oder verschiedene Versionen der BPL´s, die dann wieder irgendwo lokal herumlungern müssen. Man kann sich das Leben auch schwer machen :wink:

[hoika]

Hallo,
also die BPLs der verschiedenen Versionen sollten schon versionsbezogene Namen haben ...
Und zum Test muss man eh verschiedenn "leere" Rechner (virtuelle Maschinen) haben.

Aber auch wir benutzen keine Packages, aus schon gesagten diversen Gründen.

[TRomano]

Ja, das haben sie auch ...
Ob allerdings eine "cxDataRS24.bpl" (DevExpress) aus der Version 15.2.4 kompatibel mit der 15.2.5 ist (bei gleichem Namen), ist eben nicht sichergestellt. Da kommen schon mal gerne die Fehlermeldung, dass eine Func/Proc nicht an einer bestimmten Adresse gefunden werden kann.

[jaenicke]

Deshalb kann man ja auch einstellen welche Packages als Runtime Packages eingebunden werden sollen. So kann man das auf die von Delphi selbst beschränken.