Including shared libraries

[Johan Vromans]

Hi,

pp automatically includes libperl.so and the .so's for the XS modules.

Can it be made to include all necessary system libraries as well?

For example, when I package a wxPerl program, the resultant executable
requires compatible wxWidgets libraries to be present on the target system.
I would like to avoid that.

-- Johan

[Ch Lamprecht]

On Thu, 30 Jun 2016 00:14:00 +0200

pp executables are not as stand-alone as the ones from Cava and
PerlApp.

Care to elaborate?

Sure.
I've been working with PerlApp for many years (up to 2013) to deliver
commercial, wxPerl based Windows applications. From 2008 I (also) used Cava
Packager in combination with Citrus Perl to deliver cross-platform (Linux,
Windows, OSX) wxPerl based applications.
The main goal was, and still is, to deliver something to the user that just
works without hassle. Currentday users do not know, nor care, about
operating systems, Perl, wxWidgets and so on. They click to install, and
click to run.

With pp they don't even have to install, they click and it just runs fine. I'm
using pp now for 10 years to deliver an executable that includes Postgres client
libraries and Tk UI. It works fine on Linux MacOS and Windows.
Thanks to Roderich for all the work!

Cheers, Christoph

[Johan Vromans]

On Sat, 2 Jul 2016 09:30:30 +0200

Post by Ch Lamprecht
With pp they don't even have to install, they click and it just runs
fine. I'm using pp now for 10 years to deliver an executable that
includes Postgres client libraries and Tk UI. It works fine on Linux
MacOS and Windows.

pp is a great tool, and I'm very happy that its there. Once I worked out
the tedious process of getting the necessary libraries included it produces
functional binaries and that's just about all to ask for.

Nevertheless why not try to get the best of both worlds. Cava Packager has
some features that would make life easier for pp users too.

For example, Cava Packager provides Cava::Packager, a license-free module
(see http://www.cavapackager.com/appdocs/utilities.htm) that is very handy
when developing programs that will be packaged. For example, the functions
abstract out whether the application is running bare (unpackaged, e.g.
during testing and development) or packaged. There are functions to get
access to packaged data and so on. I have wrapped Cava::Packager in a
custom App::Packager that also supports pp packaged applications. One of
the most relevant functions is GetResource, which will provide the actual
path name of a given resource no matter whether it is packaged by pp, Cava,
or not at all.

It seems to me that this would be a nice addition to pp, too.

-- Johan

[Johan Vromans]

On Sat, 2 Jul 2016 17:42:27 +0000

Cava Packager has some features that would make nice additions to pp but
it seems that the Cava's current license precludes using Cava code which
means developing the features from scratch unless we can get Cava's
author to release the code which seems unlikely.

The last time I had contact with Mark he was working on Citrus Packager, an
improved derivative of Cava Packager which was to be released under an Open
Source license. Just before I saw your mail I made (yet another) attempt to
get in touch with him.

-- Johan