in reply to Re: targetting for multiple perl versions
in thread targetting for multiple perl versions

Spot on.

I guess coordinating with I.T is the way to go. :-| The other way is probably to offload processing to server and do minimal work on different OSes/platforms.

  • Comment on Re^2: targetting for multiple perl versions

Replies are listed 'Best First'.
Re^3: targetting for multiple perl versions
by dasgar (Priest) on Oct 01, 2015 at 22:30 UTC

    From my point of view, sundialsvc4's points are only valid if you're supplying only source code and are expecting the production systems to have the environment needed to properly run the source code. But that's not the only method to get your code to work on another system.

    Take a graphical web browser (Chrome, Firefox, Safari, etc.) as an example. Those companies are not providing source code and instructions on what kind of compiler (and libraries and tools and other stuff) you need and instructions on how to configure all of that to properly compile and run their code. Instead, they provide a stand alone executable. Going that route, there is no need to be concerned about the state/configuration of the development tools on systems or even if there are any development tools installed. Instead, just run the executable. That's it.

    Translate that your Perl code, you could package your code into a stand alone executable and the distribute that executable. Then you don't have to worry with questions like "is Perl installed?", "what version of Perl is installed?", "are the modules that I need installed?", "what module versions are installed?", etc. Just run the executable. One method for doing that is to use PAR::Packer as I described in my earlier response. And going this route eliminates virtually all of the issues raised in sundialsvc4's post.

    I'm not trying to say that anyone is right or wrong. Just tossing out another point of view for you to consider.