in reply to Help with pp - Perl Packer

There is another possibility, since the office PCs do have Perl. Through the use of use lib, a Perl program can reference additional modules stored in an alternative location on the office PCs.

(You don't say what OS your PCs are running, but this works on any OS that Perl runs on.)

#!perl use warnings; use strict; use lib qw( C:/OurPerlMods ); use NonCoreMod; # because of 'use lib' above, will find in C:/OurPerlM +ods

Where you put the "alternative" library of modules isn't important. One possibility would be to a create a zip file with your program and the extra modules it needs. Then users would unzip it to where ever you tell them to and could run the program.

If your PCs are running MS Windows, you could create an installer using, for example, NSIS, which is an open source installer builder for MS Windows.

Replies are listed 'Best First'.
Re^2: Help with pp - Perl Packer
by perloHolic() (Beadle) on Feb 02, 2015 at 09:27 UTC

    Ah, now this is interesting. I spent some time with this problem after work on Friday, and I seemed to have taken a step forward - I now have an executable, that I unzipped to see what was inside. It does indeed contain the modules that are need for that code. So I do believe that what I actually have is a viable working executable.

    However, this still leaves me puzzled as to why it displays incorrectly, still showing the :not an identifier output, upon startup and during the program? this may be unrelated to the executable creation, so perhaps this is now a different topic to discuss? If so, can anybody (more experienced in the monestary) kindly let me know if I should continue here, or start a new thread?

    Many thanks as always