Teile eines XS-Modules mit Inline::C testen

27/02/2009 - 13:30 von Gregor Goldbach | Report spam
Moin,

ich habe ein eher esoterisches Problem: Ich möchte Teile eines Moduls,
das in XS geschrieben ist, mit Inline::C testen.

Insbesondere geht es hier auch gerade um Hilfsfunktionen, die nicht von
Perl aus erreichbar sind und es auch nicht sein sollen.

Konkret laufe ich gerade gegen eine Wand, die verhindert, dass die aus
dem XS erzeugte .so nicht zu dem Test hinzugelinkt wird. Das führt dann
natürlich dazu, dass die Funktion, die ich eigentlich testen möchte, zur
Laufzeit nicht gefunden wird.

Ich habe daher das Gefühl, dass ich die LDDLFLAGS geeignet setzen muss.
Bisher hatte ich aber keinen Erfolg damit.

Hat jemand der hier Mitlesenden schon einmal ein àhnliches Problem
gehabt? Falls ja, wie sah die Lösung aus? Gab es überhaupt eine? ;-)

Ich denke, dass es eine Lösung geben sollte. Mir fàllt nur leider nicht
die magische Inkantation ein...

Vermutlich mag es auch einfacher sein, für den Fall der nicht von Perl
aus erreichbaren Funktionen ein Testrahmenwerk für C zu nehmen (CUnit
o.à.). Habt ihr damit schon Erfahrungen gemacht?

Mit etwas Glück gibt's die Lösung ja auch einfach im $foo Magazin #10 >;-)

Danke vorweg,
Gregor

Dipl.-Inform. Gregor Goldbach (PKI Team), DFN-CERT Services GmbH, Phone:
+49 40 808077-621

DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstraße 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

DFN-PKI: https://www.pki.dfn.de/
 

Lesen sie die antworten

#1 Ferry Bolhar
28/02/2009 - 23:46 | Warnen spam
"Gregor Goldbach" schrieb im Newsbeitrag
news:

ich habe ein eher esoterisches Problem: Ich möchte Teile eines Moduls,
das in XS geschrieben ist, mit Inline::C testen.

Insbesondere geht es hier auch gerade um Hilfsfunktionen, die nicht von
Perl aus erreichbar sind und es auch nicht sein sollen.

Konkret laufe ich gerade gegen eine Wand, die verhindert, dass die aus
dem XS erzeugte .so nicht zu dem Test hinzugelinkt wird. Das führt dann
natürlich dazu, dass die Funktion, die ich eigentlich testen möchte, zur
Laufzeit nicht gefunden wird.



Wie sieht deine Testumgebung aus?

perl -Mblib ...

funktioniert nicht?

Ich habe daher das Gefühl, dass ich die LDDLFLAGS geeignet setzen muss.
Bisher hatte ich aber keinen Erfolg damit.



Die LDFLAGS bestimmen m.W. nur, ob und welche Flags beim Aufruf zum
Laden des .so angegeben werden. Ich habe sie bisher noch nicht gebraucht.

Wenn sich die <modul>.pm-Datei deines Moduls im Verzeichnis <dir> befindet,
so wird die zugehörige .so/.dll Datei in <dir>/auto/<modul> erwartet, also
z.B.

.pm-Datei: lib/B.pm
.so-Datei: lib/auto/B/B.so

Du kannst das natürlich àndern, wenn du auf den Gebrauch von DynaLoader.pm
bzw. XSLoader.pm verzichtest und die .so Datei selber làdst. Aber das ist
normalerweise nicht nötig. Auch die durch MakeMaker bereitgestellte
Verzeichnisstruktur entspricht der obigen Konvention. Wie es Inline::C
damit hàlt, weiß ich nicht, aber das dynamische Laden von Code wird
immer über DynaLoader/XSLoader abgewickelt und daher sind diese
Konventionen immer vorgegeben.

Hat jemand der hier Mitlesenden schon einmal ein àhnliches Problem
gehabt? Falls ja, wie sah die Lösung aus? Gab es überhaupt eine? ;-)



Wie gesagt, man kann zu Testzwecken auch DynaLoader::dl_load_file
direkt aufrufen und den absoluten Namen der .so-Datei direkt angeben.
Es wàre aber sicher sinnvoller, durch Debuggen von DynaLoader.pm
festzustellen, wieso die Datei nicht gefunden wird - und, ob sie wirklich
nicht gefunden wird, oder ob das Laden nicht aus einem anderen Grund
schiefgeht. Bekommst du beim Ladeversuch eine Fehlermeldung? Falls
ja, welche?

Vermutlich mag es auch einfacher sein, für den Fall der nicht von Perl
aus erreichbaren Funktionen ein Testrahmenwerk für C zu nehmen (CUnit
o.à.). Habt ihr damit schon Erfahrungen gemacht?



Ich schreibe für solche Fàlle von Perl aufrufbare XS-Jackets. Die nehmen
einfach die entsprechenden Argumente entgegen, führen mittels Typemaps
die notwendigen Konvertierungen durch und rufen dann die Funktionen
auf. Und hier sehe ich auch eines der größten Probleme von Inline::C:
ein Durchtesten auf diese Art ist damit nicht bzw. kaum möglich. Man
muss auf XS ausweichen, und da kann man gleich alles direkt in XS
programmieren. Inline::C ist eine nette Spielerei, wenn es darum geht,
einfache Bibliotheksroutinen von Perl aus aufrufbar zu machen, Für alles
anderes ist es ungeeignet, weil es zuwenig Testmöglichkeiten vorsieht.

LG, Ferry

Ähnliche fragen