On approximately 5/27/2003 10:57 PM, came the following characters from the keyboard of John:
----- Original Message ----- From: "Autrijus Tang" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 26, 2003 5:06 PM
Subject: Survey: How important is pp --standalone?
Hi there. Since PAR 0.68's loader can now arbitrarily load libraries before executing the Perl interpreter on Win32 (via $ENV{PATH} munging) and Unixes (via $ENV{LD_LIBRARY_PATH} and execv(argv[0],argv)), PAR 0.70 will be capable to include a copy of dynamically-linked libperl.so / perl58.dll inside the executable, thereby producing a true "stand-alone" executable.
Now, I'd like to ask a few questions:
- Is this feature desired?
Yes. The perl scripts that I distribute to others are invariably used on win32 workstations that don't have perl installed on them. At the moment I am using Perl2exe to make standalone executables of them. I am, however, interested in alternative solutions.
- Should this feature be made default? i.e.
Yes - My preference as this is how I am most likely to use it.
pp foo.pl # generate standalone executable pp --dependent foo.pl # now this requires perl5x.dll
Someone else suggested: pp --no-libperl foo.pl # to inhibit default inclusion of libperl/dll
I endorse this suggestion.
- Should we compress the libperl image using zlib? Since it's quite bulky, uncompressing will take a bit time, and there will always be UPX for people wants to minize the executable size. But I'm willing to be convinced the other way.
I would prefer to keep the distributed executable as small as possible as I generally distribute either by floppy disk or email attachment. The time taken to extract the distribution package is not significant for my purposes.
I do see that extraction times may be significant for some application and it may be best to make libperl compression optional. I vote for compressed libperl as the default condition.
I agree with all of John's responses in this survey.
Regarding this last issue, machines are fast these days, so extraction time is not a big issue.
I'm just starting to investigate par & pp, looking for a technique for packaging and distributing some perl scripts I've written to some non-literate people, and really haven't used it yet, but if a pp-built executable extracts its components to a directory structure before running, a 2nd execution could conceivably be faster by leaving the directory structure intact from the first execution? Perhaps doing so could be controlled by packaging options.... but overridden by a couple environment variables on the target machine...
I have no clue what UPX is....
-- Glenn ===== Wise men talk because they have something to say. Fools talk because they have to say something." -- Plato
