Opened by roli at 2012-08-13 10:01
User since
2009-10-11
30 Artikel
BenutzerIn
![[default_avatar]](/battie/theme/default/default_avatar.gif)
2009-10-11
30 Artikel
BenutzerIn
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)
Meine Ordnerstruktur zum verteilen unter Windows sieht in etwa so aus:
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
pre
c
cpan
licenses
perl
win32
some_files
ressource
image1.jpg
splash.bmp
icon.ico
MyModule
x.pm
y
z.pm
MyModule.pm
MyScript.pl
MyScript.lnk
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)