Laufzeit Packages XE6

[Pfaffe]

Das steht bzgl. Laufzeit-Packages in der XE6 Onlinehilfe: "Immer wenn Packages installiert und deinstalliert werden, wird die Liste der Laufzeit-Packages entsprechend aktualisiert. Laufzeit-Packages, die für installierte Entwurfszeit-Packages erforderlich sind, werden automatisch hinzugefügt."
Aber das ist wohl nicht mehr so :pale:
Wie geht das den jetzt?

[Uwe Raabe]

Zitat:

Zitat von Pfaffe (Beitrag 1264230)

Das steht bzgl. Laufzeit-Packages in der XE6 Onlinehilfe: "Immer wenn Packages installiert und deinstalliert werden, wird die Liste der Laufzeit-Packages entsprechend aktualisiert. Laufzeit-Packages, die für installierte Entwurfszeit-Packages erforderlich sind, werden automatisch hinzugefügt."
Aber das ist wohl nicht mehr so :pale:

Was bringt dich zu diesem Schluss?

[himitsu]

Wobei es ja eigentlich nicht nötig sein sollte, daß Laufzeitpackages im Packagemanager auftauchen.

Wenn ein Designtime-Package beim Laden (in der IDE oder im Programm) ein anderes Package benötigt, dann wird das automatisch geladen.



Runtime-Packages sind in der Liste eh nutzlos, da sie dort immer deaktiviert sind und somit eh nicht von der IDE geladen werden.
(die werden dann halt, so wie jedes andere Package dann geladen, wenn sie irgendwo verwendet werden)

[Pfaffe]

Zitat:

Was bringt dich zu diesem Schluss?

???

Was ist ein Packagemanager?

[Stevie]

Zitat:

Zitat von Pfaffe (Beitrag 1264248)

Was ist ein Packagemanager?

Wenn Himitsu Packagemanager sagt, meint er eigentlich den "Install Packages" Dialog in der IDE (Menü: Component->Install Packages...)

[himitsu]

Zitat:

Zitat von Pfaffe (Beitrag 1264248)

Was ist ein Packagemanager?

Die billige Ausgabe davon, welche sich hinter dem Menüpunkt "Komponente > Packages installieren" versteckt. :stupid:

[Uwe Raabe]

Zitat:

Zitat von Pfaffe (Beitrag 1264248)

Zitat:

Was bringt dich zu diesem Schluss?

???

Ich frage mich, wie du zu der Aussage kommst, daß das nicht mehr so sei. Zum Einen steht es in der Online-Hilfe zum aktuellen Delphi und zum Anderen habe ich noch keinen Fall gehabt, wo das nicht so funktionieren würde. Deshalb meine Frage, warum du meinst, daß das nicht mehr so sei. Du musst ja irgendeinen Anwendungsfall haben, wo das System nicht so reagiert, wie du erwartest. Beschreib das doch einfach mal genauer.

[Pfaffe]

In XE gehe ich in den Projektoptionen auf Packages. Wenn ich dort das Häkchen bei Laufzeit-Packages setze und dann das Eingabefeld leere, dann wird das Eingabefeld automatisch gefüllt, wenn das Häkchen bei Laufzeit-Packages einmal entfernt und wieder gesetzt wird. Erzeuge ich nun das Projekt, werden mir unter Projekt - Infos die verwendeten Packages, die ich mit weitergeben muss, angezeigt.
In XE6 wähle ich in den Projektoptionen "Packages - Laufzeit-Packages" und das Ziel "Release Konfiguration - 32-Bit-Windows Plattform". Wenn ich nun das Häckchen bei "Mit Laufzeit-Packages linken" setze dann passiert nichts. Ab jetzt verstehe ich die Vorgehensweise nicht mehr. Ein Projekt mit Laufzeit-Packages bekomme ich nicht übersetzt.

[Uwe Raabe]

OK, jetzt verstehe ich wovon du redest.

XE6 verhält sich aber genauso wie beschrieben. Bei der Installation eines Entwurfszeit-Packages werden die davon benötigten Laufzeitpackages in die Liste eingetragen. Das kannst du ganz leicht überprüfen indem du z.B. bei dem TeeChart Standard VCL Components Package den Haken wegnimmst und wieder setzt. Dabei werden automatisch die davon benötigten Laufzeit-Packages Tee, TeeDB und TeeUI entfernt bzw. hinzugefügt. Das ist aber auch genau das, was die Hilfe sagt.

Das Verhalten unter XE kann ich hier jetzt leider nicht nachvollziehen, da ich gerade kein XE installiert habe. Es ist aber durchaus möglich, daß das dortige Verhalten im Zuge der Plattform-Vielfalt und der verschiedenen Build-Konfigurationen seit XE2 nicht mehr konsistent nachgebildet werden kann.

Am Ende muss aber doch der Entwickler selbst entscheiden, welche Packages er benutzen will und welche Units direkt in die Exe eingelinkt werden sollen. Es ist ja nicht zwingend, daß beim Compilieren mit Packages immer alle möglichen Packages eingebunden werden. Man kann das ja auf eine sinnvolle Auswahl beschränken.

[himitsu]

Aso, das meinst du.

Und dann werden all diese Optionen einmal in der IDE und dann nochmal im gerade aktiven Projekt gespeichert.
Man kann also für jedes Projekt auchnochmal einzeln sagen was wann passieren soll.

Bei uns ist das auch nochmal bissl blöd:
- wir haben eine Umgebungsvariable mit den Packages für all unsere Projekte (EXE und die vielen DLLs), um das nur einmal definieren/ändern zu müssen.
- nur schaut diese "aufnehmen" Funktion natürlich nur in den string und prüft nicht, ob es in den enthaltenen Umgebungsvariablen bereits enthalten ist. (erst Vaiablen auflösen und dann schauen)

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

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1264435)

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:

Zitat von Pfaffe (Beitrag 1264833)

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:

Zitat von Pfaffe (Beitrag 1264833)

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:

Zitat von Pfaffe (Beitrag 1264833)

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:

Zitat von Pfaffe (Beitrag 1264833)

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:

Zitat von Pfaffe (Beitrag 1264833)

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:

Zitat von Pfaffe (Beitrag 1264833)

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:

Zitat von Pfaffe (Beitrag 1264833)

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:

Zitat von Pfaffe (Beitrag 1265592)

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:

Zitat von Pfaffe (Beitrag 1265592)

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.