Zu- und Unzufriedenheit mit Delphiqualität sowie Preis- und Lizenzpolitik

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1339384)

Das größte Problem ist finde ich die Packageverwaltung. Eigentlich unterscheiden sich die Packages alle nicht, aber trotzdem muss ich die alle für jede Version einzeln kopieren, weil es immer noch keine Möglichkeit gibt Einstellungen in der Projektdatei versionsbezogen zu setzen...

Indirekt schon. Wenn am Ende der BPL die Compilerversion steht, dann kann man die in der Projektverwaltung weg lassen.
Beispiel: VCL240.bpl und Abhängigkeit "VCL"

Ansonsten ja, man braucht für jeden neue Compiler-Version eine eigene BPL, falls man die BPLs nicht über die Projektverwaltung kompilieren lassen kann. (Package-Projekte in Projektgruppe).
Das liegt aber daran, dass die Packages einmal eine Versionsprüfung haben und da die RTTI verlinkt ist und da sich sowieso bei jeder RTL/VCL/FMX/Delphi-Version irgendwas an den Schnittstellen ändert.
Bei DLLs dagegen sind die Schnittstellen "unabhängig" und ändern sich nicht ständig. (außer jetzt bei 32<>64 Bit und Unicode, wenn der Entwickler da Mist gebaut hat)

[Bambini]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339387)

Zitat:

Zitat von jaenicke (Beitrag 1339384)

Das größte Problem ist finde ich die Packageverwaltung. Eigentlich unterscheiden sich die Packages alle nicht, aber trotzdem muss ich die alle für jede Version einzeln kopieren, weil es immer noch keine Möglichkeit gibt Einstellungen in der Projektdatei versionsbezogen zu setzen...

Bei diesem Post schlug mein Keyword-Trigger an 8-)

So ganz habe ich dein Problem nicht verstanden. Kannst du das etwas genauer beschrieben? Gerne auch als PM um den Thread hier nicht zu verunreinigen.

Sofern man die alten Delphi Versionen auch auch der Maschine hat und diese nutzt, müssen sich die Packagenamen unterscheiden.
Eine package1.bpl für Seattle muss unter Berlin anders heißen, da der bpl Path von beiden Delphi Versionen genutzt wird. Compiliert man das Package1.bpl mit Berlin unter dem gleichen Namen gehts nicht mehr unter Seattle und vice versa. Das wäre kein größer Heck Meck, aber wenn Packages andere Packages verwenden wir es aufwendig.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1339396)

Indirekt schon. Wenn am Ende der BPL die Compilerversion steht, dann kann man die in der Projektverwaltung weg lassen.

Genau! Der Package Magician soll ja in Zukunft noch weitere Features bekommen...

[Uwe Raabe]

Zitat:

Zitat von Bambini (Beitrag 1339398)

Sofern man die alten Delphi Versionen auch auch der Maschine hat und diese nutzt, müssen sich die Packagenamen unterscheiden.
Eine package1.bpl für Seattle muss unter Berlin anders heißen, da der bpl Path von beiden Delphi Versionen genutzt wird. Compiliert man das Package1.bpl mit Berlin unter dem gleichen Namen gehts nicht mehr unter Seattle und vice versa. Das wäre kein größer Heck Meck, aber wenn Packages andere Packages verwenden wir es aufwendig.

Genau dafür gibt es ja bei den Packages den LIBSUFFIX. Damit kann der Packagename (dproj und dpk) versionsneutral bleiben, während die bpl den LIBSUFFIX dran hängen hat. Leider gibt es in Delphi bisher keine Möglichkeit, den LIBSUFFIX automatisch vergeben zu können. {$LIBSUFFIX AUTO} for packages

[Bambini]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339401)

Zitat:

Zitat von Bambini (Beitrag 1339398)

Sofern man die alten Delphi Versionen auch auch der Maschine hat und diese nutzt, müssen sich die Packagenamen unterscheiden.
Eine package1.bpl für Seattle muss unter Berlin anders heißen, da der bpl Path von beiden Delphi Versionen genutzt wird. Compiliert man das Package1.bpl mit Berlin unter dem gleichen Namen gehts nicht mehr unter Seattle und vice versa. Das wäre kein größer Heck Meck, aber wenn Packages andere Packages verwenden wir es aufwendig.

Genau dafür gibt es ja bei den Packages den LIBSUFFIX. Damit kann der Packagename (dproj und dpk) versionsneutral bleiben, während die bpl den LIBSUFFIX dran hängen hat. Leider gibt es in Delphi bisher keine Möglichkeit, den LIBSUFFIX automatisch vergeben zu können. {$LIBSUFFIX AUTO} for packages

Wie können anhängige Packages dann das passende Package finden? Gibt es da eine Trick für den

Delphi-Quellcode:

requires

Bereich?

[Uwe Raabe]

Zitat:

Zitat von Bambini (Beitrag 1339402)

Wie können anhängige Packages dann das passende Package finden? Gibt es da eine Trick für den

Delphi-Quellcode:

requires

Bereich?

Trick ist gut :-D

Schau mal in die Requires-Clause eines beliebigen Packages. Dort findest du vielleicht sowas wie RTL oder VCL. Damit werden die DCP-Dateien referenziert. Innerhalb der DCP ist dann der tatsächliche Name der BPL versteckt, der natürlich für jede Delphi-Version unterschiedlich lautet (z.B. RTL240.bpl oder VCL240.bpl für Berlin). Ich glaube, Delphi 5 war die letzte Version, die das noch nicht konnte.

Nehmen wir mal unsere eigenen Packages PkgA und PkgB, wobei PkgA in der Requires-Clause von PkgB steht. Bei beiden Packages setzen wir jetzt den LIBSUFFIX auf 240 (für Berlin). Compilieren wir nun beide Packages werden die Dateien PkgA.dcp, PkgA240.bpl und PkgB.dcp und PkgB240.bpl erzeugt.

Jetzt kommt irgendwann Delphi Tokyo heraus. Dann ändern wir bei beiden Packages lediglich den LIBSUFFIX auf 250 und compilieren neu. Da die Requires-Clause in PkgB immer noch nur PkgA enthält, ändert sich an der DPK-Datei nur der LIBSUFFIX (wird von der IDE erledigt). Natürlich muss ich zum PkgB250.bpl das passende PkgA250.bpl ausliefern, aber deswegen muss ich das Package-Projekt nicht extra umbenennen.

Es wäre natürlich schön, wenn man für dieses LIBSUFFIX sowas wie $(AUTO) eintragen könnte, was dann immer den passenden Wert zurückliefert. Leider funktionieren alle bisherigen Ansätze dafür nicht. Deswegen der QP-Eintrag.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339400)

Genau! Der Package Magician soll ja in Zukunft noch weitere Features bekommen...

Gut wäre ja, wenn man die Projektversionsnummer vom Compiler einbauen lassen könnte und nicht für jede Compilerversion ein eigenes Projekt bauen müsste,
oder nachträglich im AfterCompile das umbenennt, was beim Debuggen bissl Probleme bereiten tut.

Zitat:

Zitat von Bambini (Beitrag 1339402)

Zitat:

Zitat von Uwe Raabe (Beitrag 1339401)

Genau dafür gibt es ja bei den Packages den LIBSUFFIX. Damit kann der Packagename (dproj und dpk) versionsneutral bleiben, während die bpl den LIBSUFFIX dran hängen hat. Leider gibt es in Delphi bisher keine Möglichkeit, den LIBSUFFIX automatisch vergeben zu können. {$LIBSUFFIX AUTO} for packages

Wie können anhängige Packages dann das passende Package finden? Gibt es da eine Trick für den

Delphi-Quellcode:

requires

Bereich?

Wie gesagt, wenn deine BPL Name{versionsnummer}.bpl heißt, dann gibst du bei require nur den Name an, ohne die Nummer.
siehe die Delphi-Packages Vcl123.bpl -> requires "Vcl"

[himitsu]

{$SOPREFIX ''}
{$LIBPREFIX ''}
{$LIBSUFFIX '240'}
{$LIBVERSION ''}
{$EXTENSION 'bpl'}

<Basisname>.dcp
<LibPrefix><Basisname><LibSuffix>.<Extension><LibV ersion>
Der Basisname kommt dann in die Requires-Liste.

Automatisch geht, aber nicht schön :stupid:

Delphi-Quellcode:

{$IF     CompilerVersion = 18.0} {$LIBSUFFIX '180'}
{$ELSEIF CompilerVersion = 18.5} {$LIBSUFFIX '185'}
{$ELSEIF CompilerVersion = 20.0} {$LIBSUFFIX '200'}
{$ELSEIF CompilerVersion = 21.0} {$LIBSUFFIX '210'}
{$ELSEIF CompilerVersion = 22.0} {$LIBSUFFIX '220'}
{$ELSEIF CompilerVersion = 23.0} {$LIBSUFFIX '230'}
{$ELSEIF CompilerVersion = 24.0} {$LIBSUFFIX '240'}
{$ELSEIF CompilerVersion = 25.0} {$LIBSUFFIX '250'}
{$ELSEIF CompilerVersion = 26.0} {$LIBSUFFIX '260'}
{$ELSEIF CompilerVersion = 27.0} {$LIBSUFFIX '270'}
{$ELSEIF CompilerVersion = 28.0} {$LIBSUFFIX '280'}
{$ELSEIF CompilerVersion = 29.0} {$LIBSUFFIX '290'}
{$ELSEIF CompilerVersion = 30.0} {$LIBSUFFIX '300'}
{$ELSEIF CompilerVersion = 31.0} {$LIBSUFFIX '310'}
{$ELSEIF CompilerVersion = 32.0} {$LIBSUFFIX '320'}
{$ELSEIF CompilerVersion = 33.0} {$LIBSUFFIX '330'}
{$ELSEIF CompilerVersion = 34.0} {$LIBSUFFIX '340'}
{$ELSEIF CompilerVersion = 35.0} {$LIBSUFFIX '350'}
{$ELSE} {$MESSAGE Error 'CompilerVersion unbekannt'} {$ENDIF}