Sun Dec 13 13:12:02 2015: Request 110307 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Option -F does not encrypt files in inc\lib
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: [email protected]
Status: rejected
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110307 >
On 2015-12-13 12:28:33, [email protected] wrote:
It's more that the docs are
Is there any way to encrypt .pl-files which are not considered
> as
> "modules" by ScanDeps? The application has a lot of subroutines which
> are included using 'do' as separate .pl-files by the main script.
>
> If there is any smart way or workaround - please let me know.
The easiest solution is to patch your version of PAR/Packer.pm like this:
--- lib/PAR/Packer.pm.orig 2015-11-19 10:07:42.016710501 +0100
+++ lib/PAR/Packer.pm 2015-12-13 18:50:00.188377284 +0100
@@ -813,7 +813,7 @@
$self->_vprint(2, "... adding $map{$pfile} as ${root}lib/$pfile");
- if ($text{$pfile} or $pfile =~ /utf8_heavy\.pl$/i) {
+ if ($text{$pfile} or $pfile =~ /\.pl$/i) {
my $content_ref = $mod_filter->($map{$pfile}, $pfile);
$full_manifest->{ $root . "lib/$pfile" } =
I could do this in general, but I'm not sure about the consequences: if someone
was using "pp -F Crypt .." with non-script .pl files before, this might break
if she was accessing the .pl files with something that doesn't ultimately
result in a do().
Another solution would be to rename all your .pl file to .al (and change all
do() statements accordingly), since Module::ScanDeps classifies these as
"autoload" and PAR::Packer treats "autoload" the same as "module". Actually, I
like this one better, since that's what your application is doing, it just uses
a similar approach as AutoSplit.
Cheers, Roderich
