On Mon, 4 Jul 2016 10:51:17 +0200
Roderich Schupp <[email protected]> wrote:
> > For example, the functions
> > abstract out whether the application is running bare (unpackaged, e.g.
> > during testing and development) or packaged.
>
> You could e.g. test for $ENV{PAR_TEMP} to exist.
Exactly. Now, Cava uses $Cava::Packager::PACKAGED. I forgot what PerlApp
uses.
So instead of having to write this all out everywhere, I have
a function:
package App::Packager;
sub Packaged {
exists($ENV{PAR_TEMP}) || defined($Cava::Packager::PACKAGED);
}
I just have to call App::Packager::Packaged() and leave the details to
the module.
> PAR has that, too, though - cough - not well documented. Just for the
> record:
>
> The PAR::Tutorial on "Accessing packed files" is wrong in the context
> of a packed executable.
> You can get an Archive::Zip object for the packed executable (which is
> actually a zip with something you don't really want to know stuck in
> front of it) with
>
> my $zip = PAR::par_handle($ENV{PAR_PROGNAME});
Ah, interesting to know...
I have the habit of placing all resources in a directory "res", and
I currently use
sub GetResource { $ENV{PAR_TEMP} . "/inc/res/" . $_[0] };
Again, there's a Cava counterpart of this routine and an unpacked variant,
so in the application I can just write
... App::Packager::GetResource("info.dat") ...
and it will return the right path name whether the application
was packaged or not.
I find this very handy. If you exclusively use PAR then it has no added
value, of course.
BTW I very much appreciate the work you do on PAR and pp. Perl really needs
tools like these!
-- Johan
