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: javier...@gmail.com 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?