Thanks for clarifying Roderich.
I've had a look at sub PAR::_extract_inc and have a plan for a separate
sub which a script can call to re-extract all the files packed using -a.
It boils down to checking for par_tmp/inc/MANIFEST and unzipping it if
needed. None of the -a packed files are listed in the manifest, so we
can then iterate over the inc directory in the zip archive and, if a
file or folder is not in the manifest and is not in par_tmp/inc, then it
can be re-extracted.
If this passes the sanity check then I'll code something up.
Regards,
Shawn.
On 17/12/2014 20:12, Roderich Schupp wrote:
On Tue, Dec 16, 2014 at 10:35 PM, Shawn Laffan
<[email protected] <mailto:[email protected]>> wrote:
PAR does add itself to @INC at run time (see example below), so
maybe adding a packed data folder to %INC, or the end of @INC to
avoid name clashes, in a BEGIN block the script would be a viable
workaround. Please do post the results.
That won't work. @INC is relevant for _loading modules_, ie. "require
something" (or "use something", as this impies the former). PAR does
indeed add itself to @INC, by adding some directories in the cache
area and by adding a CODE ref that can load modules from the packed
executable (the zip part) itself.
But all icons, data files etc are read by the modules themselves using
standard file reading ops.
PAR cannot detect this (and hence intercept this). Depending on how
these modules determine the filesystem location of their data
(unfortunately there's no universally adopted approach here) these
calls _may_
succeed if the data files have been explicitly packed (with -a).
Module::ScanDeps also cannot detect this data when it parses your
script and all required modules.
It has list of well known modules and their data, though, for example
all the Unicode data is packed and extracted to the correct location.
Cheers, Roderich
