Did anybody ever look at PAR packager?

[gordonb3]

Running on somewhat slower hardware, I've already done some work on replacing interpreted code (mostly python as this is an absolute horror with resources) I was looking at options to turn LMS into an ELF binary. Considering the size I wondered if there might be some sort of Perl compiler (which doesn't appear to be the case) and came across a thing named PAR that seems to be able to create something of a virtual app from a Perl script.

Doesn't help me and running a second instance of Perl would likely be a bad idea as well, but it might be a nice solution for people running into conflicts with other Perl consumers on bigger machines.

[mherger]

A decade or more ago PAR was the suggested packager for plugins. Until
somebody figured out a simple .zip file would do as well...

I again looked into it about a year ago, when I was wondering whether
we'll have to package LMS for OSX, as Apple announced they'd drop the
scripting languages. But I think I never got to actually get a working
archive.

On Windows we've been using a commerical packager forever (ActiveState
PerlSDK). Alas, that product is no longer recommended by the vendor...
the recommend using a Docker container instead...

FWIW: these are not compilers. They basically create an archive with all
the Perl files which then are extracted at launch time. There's no
performance improvement, if that was something you were looking for.

--

Michael

[jvromans@squirrel.nl]

On Mon, 21 Dec 2020 22:41:22 +0100, Michael Herger <slim (AT) herger (DOT) net> wrote:

> FWIW: these are not compilers. They basically create an archive with all
> the Perl files which then are extracted at launch time.

Same with the portable loader approach (albeit that the files are extracted
at install time). I have this working for Linux, Windows and MacOS.

[gordonb3]

FWIW: these are not compilers. They basically create an archive with all
the Perl files which then are extracted at launch time. There's no
performance improvement, if that was something you were looking for.

As said... Doesn't help me with respect to my intended goal.

As far as I understand though this is supposed to create a portable application which as I read it does not rely on an external Perl being installed. Therefore this method should allow e.g. a Perl version 5.18 to run LMS on a system that has Perl 5.32 installed for distro supported applications.

[jvromans@squirrel.nl]

On Mon, 21 Dec 2020 23:33:23 +0000, gordonb3
<gordonb3.9u996o (AT) no-mx (DOT) forums.slimdevices.com> wrote:

> Therefore this method should allow e.g. a Perl version 5.18
> to run LMS on a system that has Perl 5.32 installed for distro supported
> applications.

Yes, that will work. The main idea behind PAR (and PPL and AppImage) is
that you are not dependent on whatever perl version is installed. In fact,
perl is not even required.

[gordonb3]

On Mon, 21 Dec 2020 23:33:23 +0000, gordonb3
Yes, that will work. The main idea behind PAR (and PPL and AppImage) is
that you are not dependent on whatever perl version is installed. In fact,
perl is not even required.

That's how I read it, so unless the included perl in that package still references the (version dependent) system paths and you happen to have (rogue) modules installed in that path, this should pretty much eliminate every issue where people are unable to start LMS.