Editing The Perl Lazarus Workshop (section)

== PAR, wxpar, and the hidden contents of an executable ==

A working wxPerl script is not yet a distributable Windows product.

The user should not be required to install Strawberry Perl, compile wxWidgets, install CPAN modules, configure environment variables, or reproduce the developer's workshop.

PAR-based tools help collect the Perl interpreter, modules, and supporting material into a Windows executable.

The current workshop uses:

* <code>PAR::Packer</code>;
* <code>Wx::Perl::Packager</code>, which provides <code>wxpar</code>;
* and <code>App::PP::Autolink</code>, which provides <code>pp_autolink</code>.

A minimal wxPerl packing command may look simple:

<pre>
wxpar my-application.pl -o my-application.exe
</pre>

The real difficulty is often not the command. It is discovering everything the application needs.

A script which makes HTTPS requests may depend upon OpenSSL and compression DLLs which were present in Strawberry Perl's directories during development but are not automatically obvious to the packager. The program may work perfectly on the craftsman's computer and fail immediately on the customer's.

This is why <code>pp_autolink</code> has proven especially valuable in the documented workflow. It helps discover native DLLs which must be linked explicitly into the packed application.

The packaging layer therefore teaches an important lesson:

<blockquote>
A dependency which is invisible to the developer is not invisible to the user's computer.
</blockquote>

A professional result requires dependency discovery, a repeatable build command, and testing away from the development installation.

The current [[Developing and Distributing wxPerl Applications on Windows#Creating Windows EXEs|executable-building notes]] preserve this still-developing body of experience, including special cases involving HTTPS and <code>Net::SSLeay</code>.