5

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.

PS

I tried posting the topic on ActiveState's pdk forum but I don't think that interface is accepting my post because it shows my post as being unpublished with no clue as to how to publish.

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".

Jeff Holt
  • 2,940
  • 3
  • 22
  • 29
  • @ikegami No, I'm not going to install perl when my app is copied onto the user's desktop. I have intentionally made the app NOT have an installer. The build process will put the local build machine's perl into the distribution at build time. The assumption, which I believe is correct, is that (1) perlapp eliminates the need to install perl, (2) perlapp simply bundles modules and the perl rutime, and (3) copying perl-static plus using perlapp --dependent is the same thing as perlapp --freestanding. – Jeff Holt Feb 06 '18 at 05:11
  • @ikegami That depends upon your definition of the word "install". The words you chose led me to believe that you think that I'll be installing perl like one would if they were to download the perl source code and execute "make install". I intend to do nothing of the sort. – Jeff Holt Feb 06 '18 at 05:51
  • @ikegami Your last comment makes no sense because my question is about how to distribute, say, 10 perlapp-wrapped executables but save space by distributing only one perl. I don't want to "install" one perl per executable. It's a horrible waste. Besides, a perlapp wrapped executable doesn't really install anything. Yes, it writes some files to /tmp (or /var/tmp) but it doesn't install anything. That's why it's commonly referred to as freestanding. – Jeff Holt Feb 06 '18 at 05:53
  • But according to the docs, it's not freestanding with `--dependent`. It requires an external `perl`. Which `perl` were you planning on using? I thought you were going to try to "install" one heavy pkg and 9 light pkgs, and have the 9 light pkgs use the `perl` in the heavy pkg. That would be a bad idea. Maybe I misunderstood? – ikegami Feb 06 '18 at 06:08
  • @ikegami I currently have 10 heavy packages and want the equivalent of 10 light packages plus on perl used by each of the 10. So far, the only idea I have is to use --dependent and distribute the perl for which perlapp would have bundled had it been given the --freestanding directive. But I am still concerned that --dependent would cause perlapp to bundle fewer (via some bug perhaps) modules that my code uses. – Jeff Holt Feb 07 '18 at 22:25
  • Re "*perlapp eliminates the need to install perl,*", Not at all. You will need to place Perl in a place that's accessible to all 10 packages. That's the very definition of installation. – ikegami Feb 07 '18 at 22:37
  • Re *"plus on perl used by each of the 10.*", Oh, so I was right. You plan on using a perlapp to install a perl used by your 10 other packages. That's a horrible idea. That's exactly the kind of thing that will bite you in the ass. – ikegami Feb 07 '18 at 22:37
  • @ikegami perlapp --freestanding eliminates the need to install perl. perlapp --dependent does not bundle the perl runtime with the output executable. If I distribute the same perl-static that is bundled by perllapp --freestanding then the only way the distributed app can fail is if the app is circumvented to the point where the PATH includes some problematic perl before the app's executables. – Jeff Holt Feb 08 '18 at 08:26
  • Repeating yourself is useless, as is repeating myself. – ikegami Feb 08 '18 at 08:32

1 Answers1

1

Not exactly the solution you are looking for, but Win32::Packer supports that functionality. You tell it the set of scripts that form your application and it packs all of them as a single MSI installer containing all the dependencies and .exe wrappers for all the scripts.

Currently it only supports Strawberry Perl, but it shouldn't be too difficult to add support for AS Perl too.

salva
  • 9,943
  • 4
  • 29
  • 57
  • I deeply appreciate the attempted answer. Buried deep in the conversation is a semi-declared requirement that there be no installers. This, to work around a possible lack of administrative privileges for poor Windows users. Not mentioned in the question (because I presumed it was not necessary) is the requirement to support Windows, Linux, macOS. – Jeff Holt Feb 07 '18 at 22:28
  • @jeff6times7: Actually Win32::Packer can also generate `.zip` files that don't require any installation. You can just unpack the archive and execute the contained programs. – salva Feb 08 '18 at 09:16
  • That's good to know. But my primary concern was an answer to my Q1 and my Q3. That's especially true given the fact (unrevealed until now) that the build ant script for each of the 3 platforms already bundles everything that's needed in the zip (MSWin32), tar.gz (linux), and app (darwin). Making the ant script copy one more executable is trivial. That is, assuming it's the best solution. Hence my original question. – Jeff Holt Feb 08 '18 at 15:00