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

71Another obstacle to testing

Expand Messages
  • James E Keenan
    Mar 18, 2010
    • 0 Attachment
      1. Due to Perl Seminar NY on Tuesday and a memorial service on
      Wednesday, I haven't had much time for EUPXS this week. But at
      perlsemny we had a good discussion following up on the previous
      month's hacking on App::CPAN::Mini::Visit.

      2. I encountered an additional obstacle to testing revisions to
      EUPXS -- or, perhaps, a more sophisticated variation on an obstacle
      I'd already encountered.

      I was using CPAN::Mini::Visit::Simple to do an overnight run on a
      sample of 200 CPAN modules with XS that build via
      ExtUtils::MakeMaker. My sample hung at Dave Rolsky's Class-MOP-
      v0.98. Class-MOP is, I believe, one of the fundamentals of Moose.
      Dave has written a Makefile.PL that makes *very* sophisticated use of
      Module-Install. He also has his .xs source code files in a
      subdirectory called (not surprisingly) XS/. There are four such .xs
      files there.

      Class-MOP builds fine with the current EUPXS. But when I ran it
      through the latest github version of my revisions, I experienced a
      'make' failure. To oversimplify, 'make' reported that it could not
      locate the '.xsc' intermediate version.

      I don't yet have any reason to believe that my EUPXS was creating
      bad .c files from Dave's .xs source files. I think it's probably a
      testing framework thing. After all, I had to hack up a version of
      ExtUtils::MM_Unix and place it in the same directory as
      ExtUtils::ParseXS to get any builds to run at all. And when I was
      doing my original brute force inspection of all CPAN distros with XS,
      distros that used Module::Install frequently failed to build in a
      fully-automated, non-interactive mode even with the *current* ParseXS
      and MakeMaker.

      Because of the importance of Class-MOP and Moose, we will ultimately
      have to test any revised version of EUPXS against it. But at this
      stage in our process, I'm more concerned with getting *many* distros
      to build with revised EUPXS rather than *all*.

      Jim Keenan