On Thu, Jul 01, 2010 at 10:05:29AM -0400, George Greer wrote: > On Thu, 1 Jul 2010, Nicholas Clark wrote: > > >On Thu, Jul 01, 2010 at 12:45:00AM -0400, George Greer wrote: > >>Automated smoke report for 5.13.2 patch > >>f507d6f025503d42282fe562873d505fd9969d0d v5.13.2-131-gf507d6f > >>perl-win2k: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz(~2926 MHz) (x86/1 cpu) > >> on MSWin32 - Win2000 SP4 > >> using cl version 14.00.50727.762 > >> smoketime 4 hours 19 minutes (average 32 minutes 28 seconds) > > > >I had a look at your logs for this: > > > >>../cpan/Test-Harness/t/source_handler.t.....................FAILED > >> 85-97, 100-120 > >> Non-zero exit status: 34 > > > >../cpan/Test-Harness/t/source.t ................................... ok > >'perl' is not recognized as an internal or external command, > >operable program or batch file. > [...] > >Not sure what the right solution is. The test is assuming that there is a > >perl > >in PATH? Which isn't an assumption that the core build is allowed to make, > >is > >it? > > While I could put the smoke build directory in %PATH%, that seems somehow > dirty because of the magical foreknowledge it requires. If there was a > perl in %PATH% it would be Strawberry Perl, which isn't very useful for > smoke testing. Actually, I'm a little surprised I didn't accidentally > have Strawberry Perl in there. > > I can do whichever, but it certainly feels wrong to use the $PATH Perl to > test the built Perl. Yes, I think it's wrong to assume that there is a $PATH perl at all. I'm not sure how to remove that assumption on Win32 - I don't know how process invocation works. I also don't know whether it's viable to simply invoke a batch script. [Mmmm, is that test also assuming that /usr/bin/perl exists on *nix. I wonder if I can break that assumption] Nicholas ClarkThread Previous | Thread Next