On Wed, Jan 21, 2004 at 11:14:30AM -0500, Barrie Slaymaker wrote:
> On Sun, Jan 11, 2004 at 03:41:15AM +0800, Autrijus Tang wrote:
> >
> > I just gave it a try, and committed a modified PAR.pm to the snapshot
> > version (linked to from http://par.perl.org/). Can you test it a bit to
> > see if it works for you or not?
>
> This looks ok with some basic tests, thanks!
But further testing reveals that this issue is not fixed. One problem
is that the line in PAR.pm:
$INC{$file} = $LastTempFile if (lc($file) =~ /^(?!tk).*\.pm$/);
did not make it in to parl.exe which is not in the snapshot.
But, even without testing it, unless I'm missing some code elsewhere,
this does not allow a program to scan @INC for a lib tree. In order for
programs like VCP to reflect upon the modules bundled with them, the
"low tech" approach of extracting all the lib/... files (at least) in to
a normal lib structure and making @INC contain that structure and no
CODE refs.
What is the advantage of using the CODE refs in @INC?
They're sexy, but they're more complicated, more limited, and probably a
bit slower once the tmp cache is expanded.
Is there a disadvantage to just unzipping the packaged files in to a
temp dir and putting the appropriate entry in to @INC?
Also, I believe the current practice of extracting files to filenames
based on the CRC32 of the file's contents leaves some chance that two
files will have the same CRC and thus end up extracting to the same
filename. Yes the risk is low, but it's present. Matt Sergeant came
across two image files with identical MD5 hashes and that's even less
likely :).
I'd love to implement a PAR.pm patch for this, but I can't seem to get
pp to bundle the XS code for installed modules into a pp -p -B version
of VCP and I don't have VS.net here to compile parl.exe myuself. Maybe
I can figure out how to unpack and repack parl.exe and insert my own
.exe.
Thanks,
Barrie
- Barrie
