Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re: Perl Executable

by rjt (Deacon)
on Aug 06, 2013 at 11:11 UTC ( #1048090=note: print w/replies, xml ) Need Help??

in reply to Perl Executable

As others have correctly mentioned, there is no such thing as a platform-independent executable. What you're asking for is not unlike taking a generic roll of wallpaper but then trying to pre-cut one piece of it in advance to fit any wall.

How are you planning on distributing the executables? Download? CD/DVD/USB drive? Network install? Virus?

Your two best options, in my opinion, are:

  1. Package up the separate installers per the other suggestions in this thread
  2. If the functionality of your script lends itself to being run from a centralized location, consider making a browser web-app instead. That's the closest you'll come to a truly platform-independent solution that doesn't depend on an existing Perl installation.

If you go the download route, you can easily offer downloads for each platform, and in most cases, you can take a very good guess at the user's OS by inspecting the User-agent request header. (But use that as the default selection only; the header may be wrong, or users may have reason to download for a different OS.)

If you go with physical media, you can have an autorun.inf for Windows, and add some magic to the folder for OS X. See this Stackoverflow question on autoplay for OS X and Windows. There's no general autorun for Linux, which I consider a feature. :-)

For network deployments, it really depends on your deployment method, but generally you'd have parallel methods for each OS at some point in the process.

Hope this helps.

Replies are listed 'Best First'.
Re^2: Perl Executable
by marinersk (Curate) on Aug 06, 2013 at 22:03 UTC
    I am easily amused, but I find it funny that the request is essentially to take a language which is pointedly not compiled so it can be OS- and hardware- independent, and you wish to compile it without losing that feature which is why it was not compiled in the first place.

    The fading sound of my cackles will surely continue to encourage my teammates at work to select a path to the coffee machine which maintains a safe distance from me.

      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 .. on Linux) if they live ouside of the $PERL5LIB directory tree. Virtual machines are great for testing bare-metal installs.

        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. :-)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1048090]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (11)
As of 2017-01-24 12:21 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (204 votes). Check out past polls.