Creating many perlapp executables but distribute only one copy of perl

Posted by jlholt on 2018-02-05 14:52
Forums: PDK Support | OS: All / Any

I am currently distributing an application with many perlapp freestanding executables. I'd like to distribute only one copy of the perl distribution in my application and have each executable reference the one perl runtime that I'll distribute.

To do that I'm pretty sure I have to use the --dependent perlapp command line option but I don't see any documentation for what I need to distribute in addition to what I am currently distributing. I have some questions.

Q1
If I add the --dependent option to my perlapp commands, then will perlapp still bundle all modules it was previously bundling? It looks like it is (because I removed all the pdk temp files and folders) but I want to make sure.

Q2
And to distribute perl with my application in a manner that is similar to what --freestanding does, 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
Are there any licenses that I have to include in my application that I am not already including? I think the answer is "no" because I don't recall having to include them with the freestanding executables. So, it seems reasonable that an equivalent distribution architecture would have no additional requirements.

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

Q1 ) Yes, the Perl runtime is the only thing that is specifically removed by --dependent

Q2 ) Technically, no, --dependent is designed to work against a normally installed full copy of ActivePerl on the target system, and it must be the same version of ActivePerl as was used to wrap the file.

Q3 ) No ActivePerl Community Edition license allows the redistribution of a separate copy of the static linked perl, or separate copies of any other portion of the contents of ActivePerl. To redistribute, you need an OEM agreement. Without an OEM agreement, you would need to have the End User download and install the correct version of ActivePerl, and that would require them to purchase at least one Business Edition license.

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

You answers to Q1 and Q3 are quite clear. However, I'm confused by your answer in the context of what I understand --dependent and --freestanding mean and in the context of your answer to Q1.

For years upon years, I've been under the assumption that perlapp --freestanding will create an executable that has no dependencies other than the core OS dependencies such as the loader and the C runtime. The apparent behavior of the executables that I've created indicate that assumption is correct.

And if that assumption is truly correct and if --dependent causes the resulting executable to have ONLY "the Perl runtime ... removed" from the resulting executable, then why is the answer to Q2 "technically, no".

Isn't that a contradiction?

grahams
ActiveState Staff
Wed, 2018-02-14 12:02

I'm pointing out a difference between the use the tool is designed for, and what you're proposing to do with it.

This is akin to stating that a butter knife is designed to spread toppings on bread. In many cases, a butter knife can be also used quite well as a screwdriver, but a butter knife is not designed to drive screws so your results can be considerably more varied than if you use a screwdriver.

The key difference that you are missing is that the component which PerlApp removes when you set --dependent is *not* the same as any of the dlls provided in the base Perl. If that was the case, you could potentially use any Perl with any version of the PDK, since the PDK could get what it needs from the Perl. That is not the case.
--freestanding uses a specifically compiled runtime of Perl provided in the Perl Dev Kit. It must match the underlying Perl so that modules can be used, but it is not the same. It must be adapted so that it can find and use components that are not "properly installed", and therefore the O/S is unaware of.
If you remove that part, and replace it with a Perl runtime that can only find properly installed components, you are fairly likely to encounter code that can't find resources from the wrapped file. You might not be using any code that will hit this, but I certainly can't tell you that you won't.