Re: Including shared libraries

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