Not sub-PAR
From perl.org:
"This major release
features truly stand-alone executables (no need to ship libperl or
perl5x.dll anymore), customizable icon on Win32, remote PAR (use lib
' http://example.com/foo.par';), multi-architecture PAR files, digital
signatures, aggregate PAR files, and the ability to convert CPAN
distributions to PAR distributions for easy installation. Let the list
know what you think of it!"
I mentioned before that I had ported a web application for a client from
mod_perl to fastcgi so they could sell it to IIS users. I bundled the
source code up as an exe using perl2exe and was really happy with the
simplicity of distribution - whenever I send the client a new build it's
just an exe that he can overwrite the old one with. By setting up the
application to take url, authentication and querystring parameters via
command line arguments, you can actually write automated unit tests
using only a DOS batch file - no web server or moving parts required.
I like to avoid external project dependencies on small closed-source
companies, so I checked out replacing the perl2exe with PAR. Reading
the docs, I replaced:
perl2exe aboutface.fpl (my fast perl handler)
with
pp -o aboutface.exe aboutface.fpl
And out came an executable the was much smaller than the perl2exe
executable. Testing the fastcgi app in a web browser, everything
seemed to worked as planned. Magically, the app bundled up without
complaint several platform specific DLLs for log4perl, FCGI.pm,
DBD::ODBC, etc. And it just worked. Marvelous.
I've had several issues sending perl modules or applications to clients
running Windows. I've had to instruct them on downloading ActiveState's
perl, then going through either a ppm, CPAN.pm, or cut and paste
installation of dependency libraries depending on how the module was
best installed. With PAR, I can now bundle up the perl libraries for
them, and avoid putting them through the ppm or -MCPAN configuration
gauntlet.
10:03:59 AM 
|
