On Mon, 4 Jul 2016 10:51:17 +0200 Roderich Schupp <roderich.sch...@gmail.com> 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