in reply to Re^2: Perl Executable
in thread Perl Executable

So how would you suggest distributing a Perl application to users who: a) do not have the correct version of Perl installed on their machine b) do not have the dependency tree for the Perl application installed on their machine c) do not have a compiler toolchain to build an binary dependencies from source d) do not have the technical knowledge and/or permissions necessary to do a, b, and c Solving the distribution problem is why PAR::Packer exists. Maybe you only run your software on machines that you have root/administrator permissions on, but some of us have to produce distributable packages with no external dependencies. To the OP: you have to build your distribution on each platform you wish to support. PAR::Packer does not have a "cross-compile" capability. The pure Perl portions of your codebase (and dependency tree) won't change, but any XS code or other C libraries you call will need to be compiled on the target architecture and included in the package. pp is pretty good about dependency checking, but you may have to manually link in any binary dependencies (EG pp --link=libfoo.dll ... for Windows, pp --link=libfoo.so .. on Linux) if they live ouside of the $PERL5LIB directory tree. Virtual machines are great for testing bare-metal installs.

Replies are listed 'Best First'.
Re^4: Perl Executable
by marinersk (Priest) on Aug 08, 2013 at 19:48 UTC

    If I may start with a minor side trip -- I fully acknowldge these are real world problems. I have myself faced them. I do, truly, empathize with the OP's needs.

    I just found the request itself to be entertaining; and frankly it was more the wording than the request. No harm or belittlement intended.

    However, if you need a homogenus solution to work in a heterogenus environment, one way or another, you have some work to do.

    I have solved this problem four different ways in the past.

    1. About 25 years ago, I used C. I wrote a library of routines as an abstraction layer for things which were different in the various environments. I compiled a binary for each environment, established a transfer mechanism, and used that framework. Painful, but effective.
    2. About 20 years ago, I created an embarrassingly underfeatured scripting language processor in C, used the above-mentioned framework to build and deploy the binary on each platform. From then on, if the activity could be handled by that simplistic scripting language, I wrote the script, shipped it to each environment, and ran it. Otherwise, I leaned back on the original framework.
    3. About 12 years ago, I had the privilege of being in control of the base configuration of every system I needed to reach. So I settled on a version of Perl and all systems had that version installed. I distributed perl scripts and executed them and popped a cold one afterwards to celebrate the value of a homogenus execution platform inside an otherwise heterogenus environment.
    4. About 5 years ago, I could count on Perl in the Linux and Mac environments and used Perl2Exe to create executables that worked on all the Windows environments. I was not permitted more control than that. So be it.
    I am now responsible for a fairly homogenus environment. Makes it easy; it doesn't particularly matter what solution I use. It's also not as fun. :-)
[reply]

In Section Seekers of Perl Wisdom