Distribute many perlapp wrapped executables but save space by using --dependent

Posted by jlholt on 2018-02-05 21:45
Forums: PDK discussion | OS: All / Any

Summary Question

Do I simply use perlapp --dependent for each perl script and then make sure I copy perl-static to the app's bin directory (calling it perl) during the build?

Background

I am currently distributing an application with many perlapp freestanding executables, meaning they each include a bundled copy of the perl runtime.

I'd like to distribute only one copy of the perl runtime in my application and have each executable reference the one perl runtime that I would distribute.

For example, let's assume I have 10 perl scripts that make up my application. When I execute perlapp for each of the two demo scripts, I see something like this:

+ ls -l
-rw-r--r--  1 -----  staff   55 Feb  5 21:03 t1.pl
-rw-r--r--  1 -----  staff   62 Feb  5 21:03 t2.pl
+ perlapp --force t1.pl
PerlApp 9.5.1 build 300018
Copyright (C) 1998-2016 ActiveState Software Inc. All rights reserved.
Commercial license for ..................................

Created 't1'
+ perlapp --force t2.pl
PerlApp 9.5.1 build 300018
Copyright (C) 1998-2016 ActiveState Software Inc. All rights reserved.
Commercial license for ..................................

Created 't2'
+ ls -l
-rwxr-xr-x  1 -----  staff  2266356 Feb  5 21:07 t1
-rw-r--r--  1 -----  staff       55 Feb  5 21:03 t1.pl
-rwxr-xr-x  1 -----  staff  2026992 Feb  5 21:07 t2
-rw-r--r--  1 -----  staff       62 Feb  5 21:03 t2.pl

ls -l `which perl`
-rwxr-xr-x  1 root  wheel  1978336 Mar 19  2015 /usr/local/ActivePerl-5.20/bin/perl-static

In the above output, you can see that each of the two (I have 10 so far) executables is about 2Mib, one corresponding to each perl script. In each of the bundled executables, there is a perl runtime. If I were to distribute all 10 of these, then the distribution would be over 22MiB.

It seems sloppy and wasteful to force customers to effectively download the perl runtime 10 times when the app requires only one perl runtime. Obviously, the distribution is only one file but it's much larger than it needs to be. While the whole app being only one perlapp executable, the perl runtime can conveniently be bundled into the executable. But over time features (i.e., executables) are added and the wastefulness & sloppiness increases.

To do it right, I'm pretty sure I have to use the --dependent perlapp command line option. When I test the use of that option, I see a tremendous decrease in the size of the bundled executable. After removing the temp folders and executing the dependent executable it looks like it has bundled the same modules as before.

Here are my "how" questions.

Q1 (by far the most important)

If I add the --dependent option to my perlapp commands, then should I expect perlapp to bundle all modules it was previously bundling? I think the answer here is "yes" but I'd like someone like Graham Stuart to respond.

Q2

Is it true that all I have to do is make sure the statically linked perl is in the PATH when those dependent executables are executed?

Q3 (Q2 reworded for extra clarification)

Does perlapp bundle the statically linked version of perl? I think it does but, again, I want to make sure I do something equivalent.

If I use the --dependent option, then I see this:

+ perlapp --force --dependent t1.pl
PerlApp 9.5.1 build 300018
Copyright (C) 1998-2016 ActiveState Software Inc. All rights reserved.
Commercial license for ..................................

Created 't1'
+ perlapp --force --dependent t2.pl
PerlApp 9.5.1 build 300018
Copyright (C) 1998-2016 ActiveState Software Inc. All rights reserved.
Commercial license for ..................................

Created 't2'
+ ls -l
-rwxr-xr-x  1 -----  staff  108560 Feb  5 21:07 t1
-rw-r--r--  1 -----  staff      55 Feb  5 21:03 t1.pl
-rwxr-xr-x  1 -----  staff  108608 Feb  5 21:07 t2
-rw-r--r--  1 -----  staff      62 Feb  5 21:03 t2.pl

In the above output, you can see the files are so small that they cannot possibly have the perl runtime bundled. If I distribute perl-static and 10 of the above executables, then the distribution will be about 3MiB, a savings of about 19MiB.

When I unset PATH, then the executables raise an error because the perl executable isn't found. That is why I believe the distribution simply needs the perl runtime to be in the bin directory with the executables. Seems like a reasonable solution but since I didn't write perlapp, I can't really know the truth. I have to rely on someone else to tell me "yes, you are about to do the right thing and you will not get bitten 6 months later when you do x".

grahams
ActiveState Staff
Tue, 2018-02-13 15:21

--dependent introduces at least one licensing issue if used as you propose.

There is a way to create wrapped files with settings that allow the wrapped file to act as shared libraries for other wrapped files, and settings in the other wrapped files that tell them which wrapped file will be the library.

Shared libraries is the designed way to accomplish what you want; with one file acting as the shared library for Perl, and possibly other resources.

It's in the documentation shipped with Perl Dev Kit. Note that this is one of the most complicated use cases, and the docs were probably never quite detailed enough.

jlholt | Wed, 2018-02-14 01:15

I can build my own perl and distribute it to avoid the licensing problem you defined in another thread. Considering the huge savings by distributing only one perl, I'm not as interested sharing wrapped files. Those appear to be very small in comparison to the distributed perl.