A thought came to me on Inline::CPP's trouble finding
Parse::RecDescent during smoke tests. I still feel it's valuable to
find a way to squelch the fails from this issue since they're making
it difficult to smoke out real problems as development moves forward
on the module.
Currently the code in CPP.pm is:
require Parse::RecDescent;
grammar.pm also:
require Parse::RecDescent;
I could do the following:
In t/00load_prereqs.t:
if( use_ok( 'Parse::RecDescent' ) ) {
open my $outfile, '>', '../blib/prd_location.txt' or die $!;
print $outfile $INC{'Parse/RecDescent.pm'}, "\n"; # Save the
actual location of P::RD.
close $outfile or die $!;
} else {
# No point continuing the testing if we can't find it, but this
test seems to never fail.
BAIL_OUT( "*** You must install Parse::RecDescent before
installing Inline::CPP ***\n" );
}
Now in CPP.pm:
Replace "require Parse::RecDescent;" with the following:
eval{ require Parse::RecDescent; };
if( $@ ) {
if( exists( $ENV{HARNESS_ACTIVE} ) ) {
open my $prd_infile, '<', 'blib/prd_location.txt' or die $!;
chomp( my $location = <$prd_infile> );
require $location;
} else {
die $@
}
}
I would also place a similar 'failsafe' into grammar.pm.
So the strategy is this: We know that 00load_prereqs.t seems to pass
everywhere I've seen, and that it tests use_ok( 'Parse::RecDescent' ).
So once that test completes $INC{'Parse/RecDescent'} will contain the
full path to where Parse::RecDescent resides. We write that to a file
in blib (or some other directory where it won't get in the way). Then
CPP.pm and grammar.pm each will go through their normal 'require
Parse::RecDescent;' but inside of an eval{}. If it fails, we trap the
error and load from our file the location of where Parse::RecDescent
was really found. Now we use the require "full/path/to/module"
version of 'require' to load the module from exactly where we know it
should reside.
...or if the module fails to load the first time through, we could
open the location file, read it, and push the location onto @INC.
Then repeat the normal 'require'.
We're testing $ENV{HARNESS_ACTIVE} to ensure that we're actually
running under the test harness. If we are not, the module either
already passed its test suite and is installed, or tests are being run
individually (so we can't guarantee the location file is present). My
assumption is that the P::RD issue really is related to the smoke
tests and the install phase, and that once Inline::CPP is actually
installed it clears itself up. That's only a hunch, but it really
does just look like there's a problem in how the smokers are dealing
with this particular dependency.
Of course the final code would clean up 'or die' clauses to provide
better explanations of what's going on. But I do feel the whole idea
is kind of an ugly kludge. However, it ought to work, and if it
doesn't then I'll know we have a bigger problem.
Thoughts?
Dave
--
David Oswald
daosw...@gmail.com
