71Another obstacle to testing
- Mar 18, 20101. 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
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
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*.