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

Sun Dec 13 13:35:16 2015: Request 110307 was acted upon.
Transaction: Correspondence added by [email protected]
       Queue: PAR-Packer
     Subject: Re: [rt.cpan.org #110307] 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 >


Roderich,
I never thought about the '.al'-solution but now I definitely will follow
your suggestion.
That helped me quite a lot.

Thanks and best regards
Jo
Am 13.12.2015 19:12 schrieb "Roderich Schupp via RT" <
[email protected]>:

> <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
>
>
>
>
>