Laufzeit Packages XE6

[Uwe Raabe]

Zitat von himitsu:

Hmmm, mir ist aber so, als wenn die XE6-Trial das aber richtig mit den Packagenamen befüllt hätte.

Die sind auch richtig vorbesetzt. Nur wenn man die Zeile leer macht, wird sie nicht allein durch das Aktivieren des Compilierens mit Packages neu belegt.

[Pfaffe]

Resümee:
1. Die von Embarcadero gelieferten BPLs, z.B. vcl200, unterscheiden sich nicht im Namen. Besser wäre es, wenn die für die 32-Bit Version vcl32200 und für die 64-Bit Version vcl64200 heißen würden. -> Designfehler
2. Die Ausgabeordner für eigene BLPs lauten "...\Embarcadero\Studio\14.0\Bpl\" + Win64 für 64-Bit und Win32 für 32-Bit. Jedoch wird der Win32 Ordner nicht verwendet, die Dateien landen im "...\Embarcadero\Studio\14.0\Bpl\" Ordner. -> BUG
3. In den Projektoptionen für BPLs kann ich ein LIB-Suffix angeben. Beim Kompilieren wird der aber nicht immer akzeptiert. Entweder fehlt das Suffix bei der erzeugten Datei oder er ist falsch. Man muss per Explorer in den Ausgabeordner gehen und die Datei umbenennen, bzw. man muss die bpl kopieren und unter zwei verschiedenen Namen abspeichern, denn oft gibt es Probleme auch beim Erzeugen des Designtime Pagages. -> BUG
4. Für DLLs fehlt in den Projektoptionen fehlt die Möglichkeit einen LIB-Suffix anzugeben, man muss die DLL übersetzen und dann per Explorer umbenennen. -> Das hat mit RAD nicht zu tun.
5. Ich habe eine Unit, in der sind die Functions für den Zugriff meine DLL enthalten. In dieser Unit befinden sich {$IFDEF WIN64} Direktiven. Durch diese Direktiven gibt es Zeilenverschiebungen beim Debuggen. Der Debugger ist immer ein par Zeilen zu weit oben, Breakpoints können nicht vernünftig gesetzt werden. -> No RAD, BUG
6. Generell scheint der Bereich Projektoptionen nicht durchdacht zu sein. Aufgerufen wird das Fenster mit Projekt-Optionen oder in der Projektverwaltung mit Bearbeiten (Übersetzungsfehler). -> No RAD
--> Derzeit ist XE6 als 64-Bit mit bpl Technik nicht zu gebrauchen. Ohne bpl Technik funktioniert aber alles soweit. Wer kein 64 Bit benötigt, kann nach meiner Meinung bei XE bleiben. Das Thema App-Entwicklung ist nochmals ein ganz anderes Thema. Intressant ist, das der Begriff RAD beim Delphi XE6 nicht mehr verwendet wird, auch der Ordner heißt jetzt "C:\Program Files (x86)\Embarcadero\Studio\" und nicht mahr "C:\Program Files (x86)\Embarcadero\RAD Studio".

[Uwe Raabe]

Zitat von Pfaffe:

1. Die von Embarcadero gelieferten BPLs, z.B. vcl200, unterscheiden sich nicht im Namen. Besser wäre es, wenn die für die 32-Bit Version vcl32200 und für die 64-Bit Version vcl64200 heißen würden. -> Designfehler

Im Gegenteil! Selbst Windows verwendet dieselben Namen für 32- und 64-Bit Programme und Bibliotheken. Die stehen dann halt in unterschiedlichen Verzeichnissen.

Zitat von Pfaffe:

2. Die Ausgabeordner für eigene BLPs lauten "...\Embarcadero\Studio\14.0\Bpl\" + Win64 für 64-Bit und Win32 für 32-Bit. Jedoch wird der Win32 Ordner nicht verwendet, die Dateien landen im "...\Embarcadero\Studio\14.0\Bpl\" Ordner. -> BUG

Funktioniert hier einwandfrei.

Zitat von Pfaffe:

3. In den Projektoptionen für BPLs kann ich ein LIB-Suffix angeben. Beim Kompilieren wird der aber nicht immer akzeptiert. Entweder fehlt das Suffix bei der erzeugten Datei oder er ist falsch. Man muss per Explorer in den Ausgabeordner gehen und die Datei umbenennen, bzw. man muss die bpl kopieren und unter zwei verschiedenen Namen abspeichern, denn oft gibt es Probleme auch beim Erzeugen des Designtime Pagages. -> BUG

Auch dies kann ich nicht nachvollziehen. Vielleicht wird deine Einstellung in einer abgeleiteten Konfiguration überschrieben?

Zitat von Pfaffe:

4. Für DLLs fehlt in den Projektoptionen fehlt die Möglichkeit einen LIB-Suffix anzugeben, man muss die DLL übersetzen und dann per Explorer umbenennen. -> Das hat mit RAD nicht zu tun.

Eigentlich braucht man bei einer DLL kein LIBSUFFIX. Das ist dafür erfunden worden, damit man nicht bei jedem neuen Delphi die requires Klausel eines Packages anpassen muss. So reicht es einfach z.B: RTL und VCL zu schreiben, während die BPLs dann mit dem passenden Suffix erzeugt werden. Insofern haben LIBSUFFIX und DLL überhaupt nichts miteinander zu tun.

Wenn aber nun unbedingt deine DLL eine Ergänzung zum Projektnamen haben soll, hilft dir vielleicht ein sinnvoller Eintrag in "Erweiterung der Zieldatei" weiter.

Zitat von Pfaffe:

5. Ich habe eine Unit, in der sind die Functions für den Zugriff meine DLL enthalten. In dieser Unit befinden sich {$IFDEF WIN64} Direktiven. Durch diese Direktiven gibt es Zeilenverschiebungen beim Debuggen. Der Debugger ist immer ein par Zeilen zu weit oben, Breakpoints können nicht vernünftig gesetzt werden. -> No RAD, BUG

QC?

Zitat von Pfaffe:

6. Generell scheint der Bereich Projektoptionen nicht durchdacht zu sein. Aufgerufen wird das Fenster mit Projekt-Optionen oder in der Projektverwaltung mit Bearbeiten (Übersetzungsfehler). -> No RAD

Das stimmt nicht ganz. Das "Bearbeiten" bezieht sich auf die Build-Konfiguration, deren Optionen damit bearbeitet werden. Dazu wird diese im Options-Dialog auch selektiert. Die Projektoptionen werden in der Projektverwaltung aus das Kontextmenü des Projekts ebenfalls über "Optionen" aufgerufen.

Zitat von Pfaffe:

Intressant ist, das der Begriff RAD beim Delphi XE6 nicht mehr verwendet wird, auch der Ordner heißt jetzt "C:\Program Files (x86)\Embarcadero\Studio\" und nicht mahr "C:\Program Files (x86)\Embarcadero\RAD Studio".

Das ist offenbar der Einführung von AppMethod geschuldet, das dieselbe Ordner-Struktur wie RAD-Studio verwendet (weswegen auch nicht beide auf demselben System installiert sein dürfen). Beide Produkte laufen somit unter dem Oberbegriff "Embarcadero Studio", was die Umbenennung des Ordners und die zusätzliche Verzeichnisstufe erklärt.

[Pfaffe]

Hallo, ich bins nochmal...
Danke an Uwe, mittlerweile bin ich soweit, sowohl 32-Bit, als auch 64-Bit Anwendungen mit BPL-Technik zu erstellen, jedoch derzeit nur mit den von Embacardero mitgelieferten.
Bei den Ausgabeordnern für 32-Bit bpls fehlte bei mir das $(Platform). Habe ich hinzugefügt und die Path-Variable angepasst. Vorhanden Packages habe ich bereinigt. Das mit den unterschiedlichen LIB-Suffixe für 32/64 Bit funktioniert nicht, macht aber nix, den Uwe hat Recht. Nun liegt bei mir im bpl Ordner Garnichts mehr und Path-Variablen sind richtig konfiguriert. Komischerweise hat dann aber XE6 beim Start gemeckert und gefordert, dass auch der bpl selbst in der Path-Variable aufgenommen wird. OK, habe ich gemacht, damit zickt XE6 nicht mehr. Nun habe ich mein XE6 lieb gewonnen (Ja, so sind wir Delphi-Entwickler nun mal, wir lieben und hassen unser Delphi gleichermaßen. Wir haben eben Gefühle.), dafür musste aber XE5 weichen.
Nachdem ich dann XE5 vom PC entfernt hatte, war irgendwie dann auch noch die SDK Installation, obwohl die im Unterordner 14.0 liegt, kaputt. Also habe ich erstmal meinen PC bereinigt (Registry, Path-Variable, Ordner) und dann XE6 wieder repariert, indem ich das Mobile-Pack nochmals installiert habe.
Nachdem ich nun auch noch kapiert habe, dass man im Feld Laufzeit-Packages in den Projektoptionen nicht vcl200, sondern vcl einträgt, funktioniert das Erzeugen und Starten von 32-Bit und 64-Bit vcl-Anwendungen mit Laufzeit-Packages. Was mir nicht bewusst war, ist, dass die Exe weis, welche bpl, 32- oder 64-Bit, sie aufrufen muss. Gefunden werden die bpls nur über einen Eintrag in der Pathvariablen.
Zum Test habe ich den kompletten Ordner "C:\Program Files (x86)\Embarcadero\Studio\14.0\Redist" auf meinen Win 8 Testrechner kopiert und dort in die Pathvariable "C:\MeinTestordner\Redist\win32" und "C:\MeinTestordner\Redist\win64" eingetragen. Und siehe da, meine 32Bit und meine 64-bit Anwendungen funktionieren.
Offene Punkte/Fragen:
a. Gibt es auch eine Möglichkeit, das ohne Path-Variable hinzubekommen. Ich möchte die bpls aber auch nicht in einen Systemordner ablegen? Bisher dachte ich immer die Pathvariable ist ein Überbleibsel aus der alten DOS Zeit.
b. Was passiert wenn ein anderer Delphi-Entwickler ebenfalls bpl einsetzt aber in einem anderen Updatelevel, das kann zu Problemen führen?
c. Wenn ich eine eigene bpl mit angebe, kommt beim compilieren die Meldung, dass das Never-Build Packages neu compiliert werden muss, die dpk Datei wird geöffnet und dort steht {$IMPLICITBUILD ON}. Ich habe aber beim Erstellen der Packages in den Projektoptionen unter Build-Steuerung "Wenn erforderlich" angegeben. Hier komme ich nicht weiter.

[Pfaffe]

Hier noch ein Endstatment:
In der Registry unter HKEY_CURRENT_USER\Software\Embarcadero\BDS\14.0\Li brary\Win32 und HKEY_CURRENT_USER\Software\Embarcadero\BDS\14.0\Li brary\Win64 gibt es einen Schlüssel "Package Search Path", dort muss auch das $(Platform) am Ende stehen.
Dann ist es ratsam, die eigenen Projektordner zu bereinigen, d.h. am Besten alles was nicht zwingend an Dateien benötigt wird, weglöschen. Ggf. ist noch sinnvoller, die Projekte neu aufzubauen. Dann funktioniert das auch mit den Laufzeit-Pagages. Bei den eigenen Packages als Lib-Suffix 200 angeben. Achtung: Der Lib-Suffix darf sich nicht zwischen der 32- und 64-Bit Version unterscheiden. Im Projekt gebt Ihr dann unter Laufzeit-Packages die Datei ohne Suffix an. Wenn die 64-BPLs benötigt werden, dann nicht vergessen, diese auch zu erstellen.

[himitsu]

Zitat von Pfaffe:

In der Registry unter HKEY_CURRENT_USER\Software\Embarcadero\BDS\14.0\Li brary\Win32 und HKEY_CURRENT_USER\Software\Embarcadero\BDS\14.0\Li brary\Win64 gibt es einen Schlüssel "Package Search Path", dort muss auch das $(Platform) am Ende stehen.

Und warum darf man nicht in den IDE-Optionen nachsehen und muß stattdessen wild in der Registry rumwuseln?

[Pfaffe]

Zitat:

Und warum darf man nicht in den IDE-Optionen nachsehen und muß stattdessen wild in der Registry rumwuseln?

Für den Schlüssel "Package Search Path" finde ich nichts in den Optionen.

[Uwe Raabe]

Zitat von Pfaffe:

In der Registry unter HKEY_CURRENT_USER\Software\Embarcadero\BDS\14.0\Li brary\Win32 und HKEY_CURRENT_USER\Software\Embarcadero\BDS\14.0\Li brary\Win64 gibt es einen Schlüssel "Package Search Path", dort muss auch das $(Platform) am Ende stehen.

Eigentlich ist das nur bei Win64 nötig und da steht es von Haus aus schon drin. Den Platform-Eintrag bei Win32 brauchst du nur deswegen, weil du den Standardausgabepfad (bpl) in das Unterverzeichnis bpl\Win32 geändert hast. Der originale Win32-Pfad (bpl) ist aus Kompatibilitätsgründen zu älteren Delphi-Versionen beibehalten worden. Für Win64 hat man dann das entsprechende Unterverzeichnis eingeführt.