[XE8] Package kann nicht installiert werden

[Cubysoft]

Das werde ich gleich versuchen. Ich frage mich nur, warum ich nicht die compilerten Dateien (bpl und dcu) von meinem PC für meinen Laptop nutzen kann. Die BPLs sind doch schon compilert..

EDIT: Es hat funktioniert, wenn ich das Package auf meinem Laptop nochmal erneut compiler.. Aber wieso muss ich das denn machen?

[milos]

Zitat:

EDIT: Es hat funktioniert, wenn ich das Package auf meinem Laptop nochmal erneut compiler.. Aber wieso muss ich das denn machen?

Keine ahnung, muss dir jemand anders beantworten. Ich neme mal an wegen der Kompatibilität? ^^

Freundliche Grüsse

[Cubysoft]

Das ist ja eben das lustige.. Auf beiden PCs liegt die selbe Version von XE8. Eventuell liegts daran, dass die BPLs nicht im BPL-Ausgabeverzeichnis lagen, komisch ist das aber trotzdem.

[jaenicke]

Die müssen soweit ich mich erinnere (habe ich schon lange nicht mehr versucht) im Systempfad liegen, nicht notwendigerweise im BPL-Verzeichnis. Das heißt, wenn du weitere Komponenten woanders hinlegen möchtest, musst du die Ordner nur in die Umgebungsvariable PATH hinzufügen. Allerdings ist diese auf etwas über 2000 Zeichen begrenzt, deshalb sollte man dort sparsam sein.

Wir haben z.B. nur ein Ausgabeverzeichnis für die ganzen .dcu Dateien und nutzen ansonsten das BPL-Verzeichnis.

[Pfaffe]

Das hier zeigt das Dilemma, als Delphi-Entwickler ist man schon Spezialist, wenn man eine Komponente in einer akzeptablen Zeit installieren kann.
"Systempfad", "Umgebungsvariable PATH", das darf doch nicht wahr sein.
Embarcadero muss sich entscheiden, soll Delphi (a) ein überteuertes Tool für Hobbyprogrammierer sein oder (b) eine RAD Entwicklungsumgebung für den professionellen Einsatz, bei dem der Preis für das Entwicklungssystem nicht so ausschlaggebend ist, wenn die Qualität stimmt.
Pascal/Delphi war mal ein Tool mit dem ich als "nicht" Informatiker eine Software selbst wirtschaftlicher bzw. schneller entwickeln konnte, als wenn ich diese an Fremdfirmen vergeben habe. Ich konkurriere nicht nur mit .Net oder Java Entwicklern, sondern auch damit, ob eine Software selbst gemacht oder außer Haus vergeben wird. Meinem internen Auftraggeber interessiert es nicht, ob das Softwaretool mit c++ oder Basic entwickelt wird und ob das Entwicklungstool 3000 oder 4000 EUR im Jahr kostet, den der Fachidiot vor dem Bildschirm kostet ihm das pro Monat. Er will, dass die blöde App in 4 Wochen fertig ist und funktioniert. Er und ich wollen nicht hören, dass man heute doch gar nicht mehr mit Pascal entwickelt, dass Delphi nur noch von "Alten" Softwareentwicklern eingesetzt wird.
GetIt ist ein guter Anfang, bitte weiter so!
PS. Wie kann ich bei GetIt, die C++ Dinger und die bereits installierten Komponenten ausblenden? Werden die bereits installierten Komponenten geupdatet? Kann ich darauf vertrauen, dass die Komponenten auch nach einem Update weiterhin funktionieren. Wer ist haftbar, wenn dies nicht ist ist?
Bitte nicht antworten.

[TRomano]

Na ja, "überspezialisierter Entwickler" muss man wohl nicht sein, eher sollte man sich mal mit seiner zu benutzenden IDE beschäftigen ... wenn ein Komponenten-Package nicht über einen Installer, der die Pfade setzt oder die voreingestellten Pfade (BPL directory) benutzt, eingespielt wird, dann muss man sich halt selbst ein wenig kümmern.
Dann stellt man eben in den Optionen des zu installierenden Package die Ausgabeverzeichnisse ein. Und man sollte sich bei vielen packages eben auch mal Gedanken machen, wie es Sebastian Jänicke vorgeschlagen hatte.

Gruß Thomas

[Uwe Raabe]

Die Packages der PngComponents sind so konfiguriert, daß man über die Projektgruppe "Alles compilieren" und dann das Design-Package installieren in jedem halbwegs normal installierten Delphi ab D2009 zu einem lauffähigen System kommt. Dazu werden die BPLs und die DCPs automatisch in die Standard-Verzeichnisse gelegt und die DCUs landen in einem Unterverzeichnis des Projektverzeichnisses der Delphi-Version. Einfacher kann man es einem Delphi-Entwickler kaum machen.

Will man das Compilieren und Installieren bei bereits vorhandenen BPLs uns DCPs vermeiden, muss man genau dies von Hand erledigen: BPL-Dateien in den Standard-BPL-Pfad und DCPs in den Standard-DCP-Pfad kopieren. Die findet man unter Tools - Optionen - Umgebungsoptionen - Delphi-Optionen - Bibliothek bei Package-Ausgabeverzeichnis und DCP-Ausgabeverzeichnis.

Das System-Verzeichnis braucht in diesem Fall nicht angetastet zu werden. Das wäre nur dann notwendig, wenn man eigene Programme mit Packages compiliert.

Ich habe mich übrigens bewusst gegen einen Installer für die PngComponents entschieden. Ich finde, ein Delphi-Entwickler sollte schon wissen, wie man ein Package installiert. Wenn nicht, muss man es eben einmal gezeigt bekommen und (wie sagt Sir Rufo immer) "der Drops ist gelutscht".

[Bernhard Geyer]

Für den Professionellen Einsatz hat Emba mit der Unterstützung von MSBuild schon einiges getan.
Das einrichten einer vollständigen IDE ist (wenn man die Vorbereitungen gemacht hat) in wenigen Minuten erledigt.

Vorbereitung:
1, Installation IDE
2, Installation GExperts, IDEFixPack, ...
3, Installation CVS (Fällt weg wenn das in der IDE integriert ist)


Einrichten
1, CVS konfigurieren und Quellcode auschecken
2, Beschriebene Suchpfade in IDE eintragen
3, Batch-Datei (Verwendet MSBuild) ausführen
4, BPL's zur Packageinstallation auswählen

Fertig!


Für den Hobbyentwickler könnte GetIt das natürlich vereinfachen da er kein CVS angelegt hat und den Aufwand der Batchdateien nicht getrieben hat.

[Sir Rufo]

@Uwe Raabe

Mit dem Erzeugen der Projekt-Gruppe habe ich aber nicht jeden Aspekt erschlagen.

Es fehlt das Eintragen der Pfade (Such, Bibliothek, Debug-DCU) und das Erzeugen der Release und Debug-DCUs. Sehr oft sehe ich bei den Packages, dass dort die Debug-Konfiguration ausgewählt ist.

Wer möchte denn bitte in dem fertigen Produkt Debug-Code laufen haben? Ich nicht und es gibt eben Einstellungen im Projekt dafür:

• Release - ganz ohne Debig-Code
• Debug ohne Debug-DCU - nur mein eigener Kram mit Debug-Code
• Debug mit Debug-DCU - alles was geht mit Debug-Code

Um das zu erreichen muss der gesamte Code pro Platform 2x erzeugt werden plus ein weiteres Mal für das DesignTime-Package.

Wenn mehrere Sprachen unterstützt werden, dann werden sogar noch mehr Erzeugungs-Läufe nötig.

Anscheinend wissen das die wenigsten Komponenten-Entwickler. Vorbildlich ist hier Spring4D von Stevie zu nennen, der einen "Installer" liefert, der genau diese Aspekte komplett berücksichtigt.

Genau aus diesem Grund wäre ich schon für einen Installer.