[rt.cpan.org #110307] Option -F does not encrypt files in inc\lib

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