in reply to Re^8: I prefer not to run the latest version of Perl because:
in thread I prefer not to run the latest version of Perl because:

I had previously followed the pp_simple link. It took me to a page of code from Anonymous Monk which does not run because "wxpar" was not found, and seemed to have nothing to do with pp_simple. I had also previously looked at App::PP::Autolink in CPAN. The examples showed using "pp_simple program-name", but said nothing about what pp_simple is or where/how to get it.

Thanks again for the suggestions, but unfortunately this has become as frustrating and tedious as trying to get "pp" to produce a working executable in the first place. Right now, life is too short to keep going down rabbit trails, especially when I installed perl2exe, ran it, and got the working executable I was after. It just works.

The monetary price of "pp", et al is certainly right ($0.00), but the price in terms of time spent trying to get it to work and the accompanying frustration is just too high right now. The price I invested in purchasing perl2exe is worth every cent.

As an aside, I created a Perl program that simply printed "Hello, world!" and ran it through both pp and perl2exe. The pp executable was 6 MB and the perl2exe executable was 2 MB. I realize disk space is cheap these days, but extrapolated out for many programs much larger than 1 print statement, the space savings become significant. Yet one more reason to prefer perl2exe.

"It's not how hard you work, it's how much you get done."

  • Comment on Re^9: I prefer not to run the latest version of Perl because:

Replies are listed 'Best First'.
Re^10: I prefer not to run the latest version of Perl because:
by swl (Prior) on Feb 08, 2023 at 21:38 UTC

    What did you try with pp_autolink? Installation is via the standard process using tools like cpan or cpanm. The pp_autolink script will be installed in one of the bin dirs on your path. For a strawberry perl installed under C:\Strawberry it will be under C:\Strawberry\perl\site\bin. It can also be found using where pp_autolink at the cmd prompt.

    In regards to the file sizes, extrapolation from a single data point is prone to a high degree of uncertainty.

    A better test would be to pack three or more executables, each with increasing complexity and dependencies. I suspect you will the difference is fixed at 4MB, as opposed to a three to one ratio.

    There is also the -z flag with pp to increase the compression level. The default is 6, and setting it to 9 will maximise the compression level and produce smaller files (see https://metacpan.org/pod/pp#-z,-compress=NUMBER). It makes almost no difference with a simple print 'hello' script, but will help with more complex set ups.

[reply]
[d/l]
[select]
      I installed App::PP::Autolink and used pp_autolink to create some executables in a test area. I received a lot of error/warning/info messages (shown in the sample run for one of the programs below). The executables started up, but I am running a full set of regression tests to avoid any "surprises".

      Until I am satisfied there are no hidden "gotchas" in the pp_autolink executables I will continue to use perl2exe for production code. Like I said, the disk space usage is not a big concern. It was just an aside. 

      pp_autolink -o=pai.exe p.pl
# Use of runtime loader module Module::Implementation detected.  Resul
+ts of static scanning may be incomplete.
# Use of runtime loader module Module::Runtime detected.  Results of s
+tatic scanning may be incomplete.
DLL check iter: 1
DLL check iter: 2
DLL check iter: 3
DLL check iter: 4
Unable to locate these DLLS, packed script might not work: oci.dll
No alien system dlls detected
Detected aliens:
# Use of runtime loader module Module::Implementation detected.  Resul
+ts of static scanning may be incomplete.
# Use of runtime loader module Module::Runtime detected.  Results of s
+tatic scanning may be incomplete.

      [download]

      "It's not how hard you work, it's how much you get done."

[reply]
[d/l]

        The two warnings are from Module::ScanDeps. The first is from pp_autolink, the second from pp as both scan the script. They can generally be ignored if the script starts up properly.

        I am not sure what oci.dll is for, but if it is not in the system path then pp_autolink will not find it. If you know where it is then you can add it to the pp_autolink call using the --link argument with its full path. This will then be passed on to the pp call (which is also printed to the console if you want to copy it for later re-use without scanning the files using pp_autolink).

        (If oci.dll it is an Oracle dll then maybe this stack overflow link is relevant. Perhaps one of the libraries your script is calling is adding its dir to the path at runtime and so pp_autolink cannot find it.)

[reply]
[d/l]
[select]

In Section Past Polls