Unter Linux reicht eigentlich das nackte Skript, der geneigte User wird die fehlenden Module nachinstallieren können (für ein Distro-Paket fehlte mir die Masse an Installationen).

Unter Windows nutze ich den Rechner selber oder bin zumindest meist der Administrator, deswegen weiss ich ja selber was installiert werden muss.
Ansonsten nehme ich PAR::Packer für Windows-Programme.

Hallo,

ich verwende seit Jahren (professionell) das Perl-Development-Kit von ActiveState. Das ist zwar nicht ganz billig, ich habe aber im Nu eine installierbare .exe. Hinzukommt, dass es das PDK auch für Linux und Mac gibt (alle drei Lizenzen sind im Preis inbegriffen).

Beim PDK kann ich die Executables so bauen, dass der Anwender kein installiertes Perl benötigt, alle Abhängigkeiten sind in der exe enthalten.

Helmut

dem graphische tool das ich auch verbreite geb ich alles mit. es wird dann mit ner bat aufgerufen weil ich bisher zu bequem war PAR oder citrusperl zu verwenden und ich einfach vom win package von kephra kopiert hab. ging bis jetzt gut :)

Ihr machts euch aber auch alle schwierig...

Meine Ordnerstruktur zum verteilen unter Windows sieht in etwa so aus:



pre (perl runtime environment) ist dabei nichts weiter als ein Standard strawberry perl mit allen Modulen, die du benötigst

MyScript.pl und MyModule.pm,... beschreibt die von dir entwickelte Anwendung.

MyScript.lnk enthält folgendes:
Ziel: CWD/pre/perl/bin/(w)perl.exe CWD/MyScript.pl
Ausführen in: CWD
Icon: CWD/ressource/icon.ico

Damit startest du schlieslich die Anwendung. Solltest du Umgebungsvariablen brauchen, kannst du noch ein batch Script drumrum packen.

Und auch wenn auf der strawberry website etwas anderes behauptet wird, ich hab bei meinen Anwendungen noch nie Probleme festgestellt, wenn die Pfadnahmen Umlaute enthalten (ist aufgrund von internen Richtlinien manchmal nicht anders möglich). Bei Leerzeichen hatte ich aber schon mal Schwierigkeiten bei aufrufen von externen Tools.

Vorteile:
* extrem einfaches distributieren, da quasi portable
* eignet sich prima zum internen Gebrauch. Einfach auf ein Netzlaufwerk und Verknüpfung verteilen (UNC Pfade gehen auch!). Und freuen, das man kaum Stress mit updates hat.

Nachteile:
* du lieferst das >300MB große SDK mit einen Haufen für den User nutzloser Dateien mit
Dem kann aber Abhilfe Geschaffen werden, indem man z.B. über PAR oder andere Tools die Modulabhängigkeiten seiner Anwendung herausfindet. Allerdings hab ich das nach den ersten paar mal aufgegeben. War mir zu lästig und den Nutzer interessierst eigentlich nicht (Besonders bei der Netzlaufwerk-Lösung).

* mehrere Anwendung = mehrere SDK's. Aber das Problem haben die anderen Lösungen hier auch. Und wenn ich sehe, wie oft bei Java-Anwendungen ne eigene Runtime mitgeliefert wird...
Last edited: 2012-08-13 20:43:05 +0200 (CEST)

Windows: Für Kunden immer mit ActiveState PDK, m.E. erlaubt keine andere Lösung eine so schmerzlose Integration, bis hin zur Ausstattung der Applikation mit einem eigenen "richtigen" Icon (unglaublich, wieviel das ausmacht). Gerade bei Windows-Nutzern ist die Aufforderung zum "Nachinstallieren" von irgendwas auch nicht gerade werbewirksam ...
Der Preis vom PDK ist schnell relativiert, wenn man die sonstigen Frickelstunden mal berechnen würde. Meine Versuch mit PAR liegen allerdings schon Jahre zurück, vielleicht ist es jetzt flauschiger.

Ich leg mein Zeug immer auf Netzlaufwerke, die automatisch beim windows-login verbunden werden.