Loading ...
Sorry, an error occurred while loading the content.

Testing ExtUtils::ParseXS

Expand Messages
  • James E Keenan
    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
    Message 1 of 1 , Feb 6, 2010
    • 0 Attachment
      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
      problems:

      206 # --- MakeMaker tool_xsubpp section:
      207
      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 $
      (XSUBPP)
      213 XSUBPPARGS = -typemap /usr/local/lib/perl5/5.10.1/ExtUtils/
      typemap
      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
      ExtUtils::MM_Unix::tool_xsubpp().

      So, apart from the challenges that ParseXS itself poses, testing
      revisions to it are proving equally challenging.

      Thank you very much.
      Jim Keenan
    Your message has been successfully submitted and would be delivered to recipients shortly.