Front page | perl.perl5.porters |
Postings from December 2014
This looks fine to me, except that I've always been slightly mystified as to why we copy the top-level perl.exe & dll into t/ in the first place.
The short answer seems to be that t/harness uses t/TEST, which sets the perl.exe to use as simply './perl' (in _scan_test()), and chdirs into t/ if we aren't already in it. Therefore, t/perl must exist...
But why can't harness just use the top-level perl (or $^X) to run the .t scripts? That way the harness process and all the .t processes would always use the same perl.exe & dll files. Without your patch they would all be using the top-level perl.exe & dll, and we could then get rid of the copying of perl.exe etc into the t/ folder -- unless there is some need for doing that which I'm missing???
If we did that then presumably we wouldn't need all the -I..\lib stuff since the top-level perl.exe would automatically pick up the lib/ folder anyway. In fact, I'm not sure that it's necessary even now since t/harness begins with this:
BEGIN {
chdir 't' if -d 't';
@INC = '../lib'; # pick up only this build's lib
}
All tests apart from the following work with the attached patch:
t/run/fresh_perl.t
t/op/glob.t
t/op/magic.t
t/op/taint.t
t/win32/popen.t
t/win32/runenv.t
lib/ExtUtils/t/Embed.t
and at a quick glance those failures seem to be due to the tests in question assuming that t/perl and t/perlglob exist.
Presumably they could easily be fixed, but there is some merit in Win32 using t/perl just to be the same as other platforms... I just wish I knew what the reason for that was in the first place!
Thread Previous
|
Thread Next