Tuesday, October 07, 2008

Schwieriger Start mit wxPerl (PPM)

Ich bin gerade dabei, mich in wxPerl einzuarbeiten. Ich habe zwei, drei Sachen in der Hinterhand, die mit einer GUI versehen werden sollen. Perl/Tk sieht teilweise etwas veraltet aus und so ist es gekommen, dass ich mit wxPerl beschäftige.

wxPerl ist das Perl-Binding zu wxWidgets, einer Cross-Plattform GUI-Library. Da mein Standard-Editor - kephra - mit wxPerl arbeitet, habe ich auch einiges an Beispielcode.

Ich habe mir vor längerer Zeit mal wxPerl installiert. Jetzt habe ich festgestellt, dass es seitdem doch einige wichtige Änderungen gegeben hat. Da ich unter Windows arbeite und mit ActivePerl entwickle, dachte ich "kein Problem, machst Du ganz schnell mit PPM ein Upgrade". Naja, extra das wxPerl-Repository eingefügt und los gings... Installation klappt. Test auf der Kommandozeile... Fehler! Irgendwelche DLLs nicht gefunden. Pfad zu den DLLs zu der PATH-Umgebungsvariablen hinzugefügt.

Scheinbar funktioniert alles. Kontrolle der Version... Ähm, das ist aber nicht die neueste aus dem Repository. Komisch. Naja, dann lassen wir die PPM-GUI weg und machen das auf der Kommandozeile. Also dort

C:\>ppm install http://www.wxperl.co.uk/repository/Wx.ppd

eingetippt.

Wurde installiert. Kontrolle... Gleicher Fehler wie vorhin. Komisch, diese DLLs gibt es gar nicht. Und warum wurde das mit gcc kompiliert? ActivePerl ist mit Visual C++ kompiliert worden.

Im Internet gesucht und einen Hinweis darauf gefunden, dass das neueste Alien::wxWidgets installiert werden muss. Warum nur löst PPM diese Abhängigkeit nicht richtig auf? Naja, ein

C:\>ppm install http://www.wxperl.co.uk/repository/Alien-wxWidgets.ppd

hat dann geholfen. Jetzt kann ich richtig loslegen!

5 comments:

Björn said...

WxPerl ist wegen der Plattformunabhängigkeit, der aktiven Community etc. sicher anderen Paketen vorzuziehen, zumal es mit wxGlade auch einen schönen GUI Editor gibt.
Aber:
Was ich damals vermisst habe war ein gutes RichEdit Control.
In der Beziehung ist Win32::GUI für mich immernoch besser, weil relativ einfach und über MSDN auch gut dokumentiert.

ReneeB said...

Bei wxWidgets (und damit wxPerl) gibt es ein "RichTextCtrl". Das setze ich auch ein. Wenn der Pod-Editor fertig ist, stelle ich ihn auf CPAN.

Für mich es es ein Muss, dass die Bibliothek Cross-Plattform ist. Deshalb scheiden die ganzen Win32-GUI-Module für mich aus.

Alvar said...

Also, beim Kunden arbeite ich gerade zum Entwickeln auch unter Windows (und da merke ich erst wieder, wie schaurig das alles ist!). Da ActivePerl immer wieder bei diversen CPAN-Sachen herumzickt, haben wir uns für Strawberryperl entschieden und das klappt wunderbar. Außer, dass Windows sehr lansam ist, ein ./Build test braucht zweieinhalb mal länger als unter OS X auf vergleichbarer Hardware.
Das Alien-Modul musste ich bei wx unter OS X auch manuell installieren, wenn ich mich recht erinnere. Da ist wohl schon im CPAN-Paket was vergessen worden.

ReneeB said...

Ich habe Strawberry noch nicht installiert, da mich in letzter Zeit zu viele Fehler bei Modulinstallationen erreicht haben.

Ich bin mit meiner ActivePerl-Installation ganz zufrieden. Allerdings habe ich einen Vorteil gegenüber den Einsteigern: Ich weiß, wie ich Probleme mit PPM umgehen kann.

StrawberryPerl werde ich mir aber auf jeden Fall mal anschauen wenn ich ausreichend Zeit habe. Das wird zwar nicht mehr dieses Jahr sein, aber bis dahin sind wahrscheinlich ein paar Kinderkrankheiten ausgemerzt...

Richard said...

Das war noch nicht alles um Wx zum Laufen zu bringen. Hier ist, was ich getan habe um WxPerl unter Activestate Perl zum Laufen zu bekommen:

Wxwidget selber unter Windows installieren:

http://wxwidgets.org/downloads/
-> wxMSW für Windows downloaden und installieren


Perlunterstützung installieren:

ppm3
> install http://www.wxperl.co.uk/repository/Alien-wxWidgets.ppd
> install http://www.wxperl.co.uk/repository/Wx.ppd

Kleines Demoprogramm um zu sehen ob es überhaupt läuft gibt es hier:

http://wxperl.sourceforge.net/tutorial/first.pl.txt