develooper Front page | perl.perl5.porters | Postings from December 2014

[perl #123486] [PATCH] make win32 harness process use tested perl binary

Thread Previous | Thread Next
Steve Hay via RT
December 30, 2014 15:02
[perl #123486] [PATCH] make win32 harness process use tested perl binary
Message ID:
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:

    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:


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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About