Inline::C is a very happy thing, BTW. (However, Inline::C just uses the same ol' XS itself; it's just an easier way of writing it.)
Confession: It does an Immortal Body good.
| [reply] |
Inline::C is an excellent thing to start, and very interesting, and many other good words we'll say to it.
But (IMHO) sometimes it's may be not good to use it in a final version of a script, because it recompiles something on the fly, and that means not only big startup time of a script, but also you must distribute your program with C compiler.
addition: After some experiments, I found out that I was wrong and things are easier to end-user than I thought: once Inline::C compiled a code, it do not recompile it again, and just loads it on demand from a single dll file (on my Win32).
Very interesting module to play with!
Courage, the Cowardly Dog
| [reply] |
Also, there's also Inline::MakeMaker, which will (in theory, anyway -- I've never played with it) work with MakeMaker to create a normal Makefile.pl && make test install installable module. Like I said, I've never played with it; I'm not confident enough in my C, nor have I written anything that's acutaly very useful with Inline::C. (The closest I've come is a program for configuring winbond IO chips, which I can no longer test.)
Confession: It does an Immortal Body good.
| [reply] [d/l] |
yeah plaese tell me about the less "strict" way. i want to play around anyway ... but i'm going in circles, i tried h2xs and swig already, but get a) problems with dynaloader (I DON'T want dynamic loading anyway ;-) and b) segmentation faults ...
BTW: Inline::C is not what i'm looking for. the c-subroutine is already compiled with the c program that starts the perl interpreter. i used Inline::C in other projects it's quite nice and it does caching of compiled code. | [reply] |
Do not afraid to shoot your leg? You're brave man!
I did "glueing" that way: (nothing unusual, I just read perlembed and related documentation)
- #include <EXTERN.h>, #include <perl.h> somewhere at the very top of C program. #include "xsub.h" somewhere near the end, and after that all "glue" functions are placed. All those header files are in perl/lib/CORE/* directory.
- Write "glue" functions like following example:
XS(TStringsTIEARRAY) {
dXSARGS;
SV *ssv=ST(0); // "G::TStrings"
void* tmp[4];
memset(tmp,0,sizeof(tmp));
tmp[2] = 0;
((TStrings*)(tmp[0])) = TyingStrings;
((TComponent*)(tmp[1])) = TyingComp;
((int)(tmp[2])) = TyingOpt;
SV *tsv;
tsv = newSVpv((char*)&tmp[0],16);
STRLEN len;
char *ptr = SvPV(ssv,len);
HV *stash = gv_stashpvn(ptr,len, TRUE);
SV *rsv = newRV_inc(tsv);
sv_bless(rsv,stash);
ST(0) = rsv;
XSRETURN(1);
}
Note usage of XS macro, "real" name of function will be more complicated after expansion of that macro.
- initialize your perl instance(s) as perlembed.pod says you to.
- After initializing it/them, in order to make those functions visible to perl, do something like:
newXS("G::TStrings::TIEARRAY", TStringsTIEARRAY, "BCB+Perl interna
+l");
- you may want to also run following:
newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, "blablabla")
+;
to enable dynamic loading of modules.
And remember, I do not enCourage you to do that :)
Courage, the Cowardly Dog
things, I do for love to perl...
| [reply] [d/l] [select] |
thanks for the hardcore version, nice to see the simple way, but i'll do the middle way between h2xs and this one, which would be the one you mentioned before.
i'll write the xs glue at the bottom of main.xs convert it with xsubpp and link with the help of ExtUtils.
so i stay portable (between perl versions and/or platforms) ;-)
thanks for your help, i'll vote for your solution as soon as i've set up a real account :-)
| [reply] |