> >> I'm not certain which of my tester machines created this. I have a rhel5, >> rhel6, dragonflybsd and FreeBSD running- though clearly this is Linux. rhel6 >> has perl 5.10 (tragically) but that kernel version in rhel5... >>
Here is a link to reports from each of the four machines that failed to pass Inline::CPP. They each had the same failure point: Unable to locate Parse::RecDescent. http://www.cpantesters.org/cpan/report/901971e6-4170-11e1-b516-a5fe68b631f7 http://www.cpantesters.org/cpan/report/78b244b0-400d-11e1-8ca1-7ac96d193cba http://www.cpantesters.org/cpan/report/96186b3e-4007-11e1-b049-6428dd1ea774 http://www.cpantesters.org/cpan/report/5e79edae-3fff-11e1-9fbe-44e45e9ffb60 The first is the FreeBSD box running Perl 5.14.2. The second is the Dragonfly box running Perl 5.12.2. The third and fourth seem to be platforms running Perl 5.10.1. The easiest way to find the reports for a developer's version of a CPAN module is to go to the main distro, click on the 'view reports' link, and once on the CPAN Testers Reports page click on "Static Website". Rob made the point that once the Parse::RecDescent issue is resolved the "I currently know... C, Foo, foo" issue should go away too. I think that's probably correct. I don't know if Damian Conway's version numbering is at the heart of what's causing this, but I do know he's broken away from the standards described in perlmodstyle; In particular he's not handling dev version numbering properly. He should be doing this: our $VERSION = 1.085_006; $VERSION = eval $VERSION; The reason is explained in perldoc perlmodstyle. This MAY be an issue, but I added code to Inline::CPP several dev. releases back that should have made Inline::CPP more forgiving of funky version numbering, and at the same time submitted a bug report and a patch to the P::RD people. ...so this shouldn't be an issue, but in the absence of other theories it sticks in my mind. > I'm wondering if $ENV{PERL5LIB} somehow gets messed with when the > Inline::CPP test suite is run. > > It would be interesting to see the output of the same build if the first of > the test scripts (t/01basic.t) was modified to begin with: > > BEGIN {warn "\$ENV{PERL5LIB}: $ENV{PERL5LIB}\n";}; > > I don't know how easy (or otherwise) it is for you to give that a try. > At least we'd then know if PERL5LIB is still set correctly or not at that > point .... where we'd go from there, I'm not sure :-) > > Do you have similar types of FAIL reports with any other modules ? Or is it > just with Inline::CPP ? > > Cheers, > Rob If we learn that the PERL5LIB env variable needs to be massaged I could at least put some explanation into the INSTALL section of I::CPP's POD. That's not ideal, but it would be a start. I think it would be helpful to see that "BEGIN {warn..." output. Dave -- David Oswald daosw...@gmail.com
