I'm seeing what looks to be the same problem with -c and -x using my own
simple scripts (on Windows XP, using ActivePerl 5.8.8 b817). As a new
user of PAR, I was experimenting with require() and use(). The
interesting thing is, whenever I get the mkdir error, if I run the
executable a second time (and subsequent times), it works fine.
Here's my experiment in detail: t1.pl is in my working dir, t1b.pl is
in a sub-directory named mylib.
----- t1.pl
-------------------------------------------------------------------
use warnings;
use strict;
use lib "mylib";
print "\n> t1: [EMAIL PROTECTED] = " . join(",\n ", @INC) . "\n";
require 't1b.pl';
print "\n> t1: \%INC = " . join(",\n ", values %INC) . "\n";
DoIt();
-------------------------------------------------------------------------------
----- mylib/t1b.pl
------------------------------------------------------------
use warnings;
use strict;
sub DoIt() {
print "\nDid it (mylib/t1b.pl).\n"
}
1;
-------------------------------------------------------------------------------
If I execute "pp -o t1.exe t1.pl" and run the resultant t1.exe, I get a
"Can't
locate t1b.pl in @INC" error:
Can't locate t1b.pl in @INC (@INC contains: CODE(0xf0d7cc)
C:\DOCUME~1\GARYL~
1.VEI\LOCALS~1\Temp\par-garyl\cache-0ec73c4d9f4028bc48fbafc0b06ffc177bc894c
d\inc\lib
C:\DOCUME~1\GARYL~1.VEI\LOCALS~1\Temp\par-garyl\cache-0ec73c4d9f4
028bc48fbafc0b06ffc177bc894cd\inc CODE(0xe23944) CODE(0xe23a7c)) at
script/t1.pl line 8.
(previous line split to fit)
Is pp or ScanDeps not able to find this require based on the use lib?
If I execute "pp -c -o t1.exe t1.pl", the first time I run the resultant
t1.exe, I get the mkdir error:
mkdir
C:\DOCUME~1\GARYL~1.VEI\LOCALS~1\Temp\par-garyl\cache-0ec73c4d9f4028bc4
8fbafc0b06ffc177bc894cd/inc/lib/C:/: Invalid argument at
C:/Perl/site/lib/Archive/Zip.pm line 659
(previous line split to fit)
Subsequent times I run it, I get the "Can't locate t1b.pl in @INC"
error. Again, is pp or ScanDeps not able to find this require?
If I execute "pp -x -o t1.exe t1.pl", it always runs as expected.
Besides the mkdir error, is this how PAR is expected to handle a require
-- you
have to run the script using pp -x for PAR to pick it up?
With a few changes to t1.pl to use a full path to mylib in the use lib
statement, I get slightly different results.
----- t1.pl
-------------------------------------------------------------------
use warnings;
use strict;
use FindBin qw($Bin);
print "\n> t1: \$Bin=$Bin\n";
use lib "$Bin/mylib";
print "\n> t1: [EMAIL PROTECTED] = " . join(",\n ", @INC) . "\n";
require 't1b.pl';
print "\n> t1: \%INC = " . join(",\n ", values %INC) . "\n";
DoIt();
-------------------------------------------------------------------------------
The results using "pp -o t1.exe t1.pl" and "pp -c -o t1.exe t1.pl" are
the same
as before. But if I execute "pp -x -o t1.exe t1.pl", the first time I
run the
resultant t1.exe, I get the mkdir error, but subsequent times run fine.
Just for kicks, I changed the first t1.pl yet again -- I removed the use lib
statement entirely and changed the require to 'mylib/t1b.pl'. In this
case, the resultant executable always ran as expected, regardless of
whether or not I used the (unnecessary) -c or -x.
I also repeated the tests using a module. I turned mylib/t1b.pl into a
trivial module by simply renaming it mylib/t2b.pm, and created t2.pl, as
follows:
----- t2.pl
-------------------------------------------------------------------
use warnings;
use strict;
use mylib::t2b;
print "\n> t2: [EMAIL PROTECTED] = " . join(",\n ", @INC) . "\n";
print "\n> t2: \%INC = " . join(",\n ", values %INC) . "\n";
DoIt(); # in module t2b
-------------------------------------------------------------------------------
These all pp'd and ran fine, with or without the (unnecessary) -c or -x,
as expected.
... Hopefully adding some more clues ...
Garyl
Malcolm Nooning wrote:
Here is a new wrinkle.
I updated AutoLoader to 5.63
I did
nmake clean
perl -MConfig_m Makefile.PL
nmake
nmake test
Now all of the automated_pp_test.pm tests pass, including the "pp -c
hello.pl" test, but only via the "nmake test". I did the "nmake test"
twice and it all passed both times.
As before, doing "pp -c hello.pl" directly from the command line,
including in a directory that has no spaces in the path name, and then
running the resulting "a.exe" fails. As before, it fails in the same
way. Namely, with the Invalid argument at C:/perl/lib/Archive/Zip.pm
line 659
I did a print out in PAR::Packer and I could not see any %ENV elements
that have to do with par/pp/perl, other than having perl in the PATH.
... Just trying to add to the clues ...
