Wed Jan 20 17:34:29 2010: Request 52794 was acted upon.
Transaction: Correspondence added by snaury
Queue: PAR-Packer
Subject: Multiple tests failing on strawberry perl
Broken in: 1.001
Severity: (no value)
Owner: Nobody
Requestors: [email protected]
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=52794 >
I think I found what's going on. Strawberry Perl 5.10.1 switched to using
perl/vendor/lib, but
it uses backslashes for vendor in @INC, i.e.:
C:/strawberry/perl/lib
C:/strawberry/perl/site/lib
C:\strawberry\perl\vendor\lib
.
There's a line in scripts/par.pl that reads like this:
if ($Config{_delim} eq '\\') { s{\\}{/}g for @inc }
Thus transforming backslashes to forward slashes. However later on, when
processing %files
(based on %:: and %INC), it fails to take into account that pathnames there are
based on
what's in @INC, meaning e.g. PAR/Heavy.pm will have pathname
C:\strawberry\perl\vendor\lib/PAR/Heavy.pm. It fails to match against
C:/strawberry/perl/vendor. This means that anything that's in vendor/lib will
never be
packed. As a matter of fact anything that has backslashes in their path will
never be packed,
including -I blib\lib. Guess what I see in test_harness line when running test
PAR::Packer? I
see blib\lib, and that's why you are having a failure.
This makes me wonder what's this line there for? Just removing it passes all
tests and pp
becomes fully functional again (i.e. generated executables don't suddenly
depend on
strawberry installed). Was there something changed in 5.10.1 that made
backslashes in
@INC work differently?
