- In the last week I've started to think about ExtUtils::ParseXS again
after a layoff of nearly five months. Here is an update.
I haven't been thinking much yet about the refactoring of ParseXS per
se. But more about how we would identify the XS in the wild we will
need to run in order to validate any such refactoring.
I recall that back in August 2009 I put out calls for someone other
than I to construct a minicpan repository and then figure out a way
to traverse that repository to identify distributions with XS. I
didn't get any responses, and the lack of responses was a factor in
my shifting of my efforts elsewhere (Parrot and, more recently, some
new CPAN modules).
I was also under the impression that I myself didn't have enough disk
space to hold a minicpan. But last week I realized that my 6-year-
old iBook -- though very slow by contemporary standards -- has much
more disk space than my Linux VM. So, with some IRC chat with rjbs,
I build a minicpan on my laptop -- had to run it over night -- and
started to learn xdg's 'visitcpan' program.
I wrote a little program which examines a distribution's MANIFEST for
entries matching this pattern: m/(?:typemap|\.c|\.h|\.xs)$/ . I
got a list with 1716 entries. The list would need some refinement
for us to work with because, among other things: (a) it apparently
doesn't include core modules bundled with Perl itself; (b) 'minicpan'
picks up multiple versions of certain CPAN distributions when a
package appears in an older version of a distribution still present
on CPAN but not in that distro's most recent version.
I next wrote a little program that says, "Assuming we have unpacked a
distro's tarball, change into its top-level directory, determine
whether it uses Makefile.PL or Build.PL, run that program and then
run either 'make' or 'Build'. If that completes successfully --
'system' returns 0 -- then we can assume that the version of ParseXS
we are using is doing no harm."
I've only tried this with one distro so far: Audrey's Algorithm-Diff-
XS-0.04. This uses Module::Install -- with which I'm not very
familiar and which now appears to support only ExtUtils::MakeMaker
but not Module::Build. So, under the hood, we're dealing with EU::MM.
I used my little program to automate 'perl Makefile.PL && make' and
examined the resulting 'Makefile'. Here's a section that may pose us
206 # --- MakeMaker tool_xsubpp section:
208 XSUBPPDIR = /usr/local/lib/perl5/5.10.1/ExtUtils
209 XSUBPP = $(XSUBPPDIR)$(DFSEP)xsubpp
210 XSUBPPRUN = $(PERLRUN) $(XSUBPP)
211 XSPROTOARG =
212 XSUBPPDEPS = /usr/local/lib/perl5/5.10.1/ExtUtils/typemap $
213 XSUBPPARGS = -typemap /usr/local/lib/perl5/5.10.1/ExtUtils/
214 XSUBPP_EXTRA_ARGS =
Note that in lines 212 and 213 '/usr/local/lib/perl5/5.10.1/
ExtUtils/' is hard-coded rather than contained in a variable as in
line 209's $(XSUBPPDIR)$(DFSEP). This poses a problem. Once we have
refactored ParseXS, we want to test with a *different* xsubpp from
the one listed in lines 208 and 209. We would first have to figure
out a way to assign a different (tmpdir for testing) directory to
XSUBPPDIR in line 208. That would work okay for line 209. But it
would not help us with the hard-coded paths in lines 212 and 213.
This is caused by the fact that EU::MM formulates the paths in lines
212 and 213 in a way different from that of line 208. See
So, apart from the challenges that ParseXS itself poses, testing
revisions to it are proving equally challenging.
Thank you very much.