Re: [MacPerl] The long way to build XSUBs (LONG EMAIL)

[Arved Sandstrom <Arved_37@chebucto.ns.ca>]

On Tue, 6 Oct 1998, Matthias Ulrich Neeracher wrote:

> Arved Sandstrom <Arved_37@chebucto.ns.ca> writes:
> >This is how I've been building XSUBs for PPC. I'm just putting it out 
> >there for sake of discussion. I'm not a trained CompSci type; it's all OJT 
> >(my background is physics). So if you see something bizarre, please 
> >chastise me gently. :-)
> 
> Thanks for taking the effort to write this down. I'm learning a lot about build
> process improvement from such protocols.
> 
> >*IF* I had been building from scratch, I'd be running Codewarrior MPW and 
> >the current directory would be MACPERL_SRC:perl:lib:ext.
> 
> But this directory is picked by choice, right? There should be no requirements
> anywhere in the distribution enforcing a particular choice of locations.
> 
That's correct. This is quite arbitrary.

> >We'll now return to module Devel::Peek, by Ilya Zakharevitch. I take the 
> >.pm and .xs files and put them in folder MACPERL_SRC:perl:lib:ext:Devel.
> 
> And presumably also Makefile.PL.
> 
Well, strictly speaking, my procedure as I described it could live without
Makefile.PL, since I'm doing everything in it on the MPW cmd line. The
reason I ever ran it at all was to see what _you_ were doing, and to learn
from Makefile.mk. :-)

> > I also get "typemap" and "xsubpp" from lib:ExtUtils and throw them in here,
> > too (I like having everything right there).
> 
> Ouch! Bad idea. Do you have any reason for doing this?
> 
At present, now that you point it out, none. Back when I was figuring out
the procedure I'm sure _I_ had a reason - I just haven't reassessed since.
Stuff like this is why I'm asking for pointers.

> >Since it's the next
step in "perlxstut", go ahead and run 'perl 
> >Makefile.PL': you'll get Makefile.mk which is very handy to look at. 
> >(Modifying this method, look in here to see what to do for other targets).
> >This is where I part ways with the easy way to do it - I don't have dmake, for
> >starters.
> 
> Why not, if I may ask?
> 
Well, this is the real sticking point. I've looked at the dmake site
several times, and I downloaded the source once, and tried to build that
(there was evidently no binary at the time). There were enough
discrepancies between the #include's in the Macified files in dmake, and
the newer ones I had available, that after a few days of hacking I gave
up. Any pointers to something I'm missing are very much appreciated.

> >DISCLAIMER: I'm using CW Pro 3 with IDE 3.1. These libraries work for *ME* 
> >with Devel::Peek. At other times I've found that -@export NewModule.exp 
> >works fine instead of diving into the .c file and looking at what symbols 
> >to export specifically.
> 
> NewModule.exp is built by the Makefile.pm, using Mksymlists.
> 
> >Once this is done, I copy the Peek.pm to MacPerl:lib:Devel:, and copy the 
> >shared lib to MacPerl:lib:MacPPC:auto:Devel:Peek:, and call it Peek.
> 
> Yup.
> 
I'll be reviewing some of what I'm doing based on Matthias' comments, but
so far it appears to be quite robust. I have another module up and running
which is pure XSUB, deals with array and hash guts, and builds without
problems using the process listed in my previous letter.

I'd like to point out that when cutting and pasting, I left out the extra
stuff on the end of the line dealing with xsubpp. xsubpp prints to STDOUT,
so direct into a temp file, and then rename to NewModule.c.

Also, while I'll be going back and checking with regards to -@export and
Mksymlists, if you _are_ using -export, the symbols are in the .c file
produced by xsubpp, basically everything which looks like
XS_NewModule_function.

Thanks for the review, Matthias.



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch