The Perl Lazarus Workshop

This is the second essay in the series Essays about The Virtuous Perl Programmer. It follows The Perl Craftsman Returns to the Windows Desktop and explains the tools chosen for the Perl Lazarus Project.

A craftsman does not require every tool in his workshop to have been forged by the same smith.

He requires tools which are sound, tools whose purposes he understands, and tools which can be arranged into a dependable way of working.

The Perl programmer who wants to build a Windows desktop application already possesses the most important part of the workshop: Perl itself, together with the knowledge accumulated through years of writing scripts, maintaining systems, serving websites, transforming data, communicating with databases, and solving problems which did not arrive in a convenient form.

What has often been missing is not ability. It is a clear path through the remaining tools.

Perl has long had graphical toolkits, Windows modules, packaging systems, database drivers, networking libraries, and access to native code. Yet the programmer who asks a simple practical question—

How do I begin with Perl code and end with a Windows application which another person can install?

—may discover that the answer is distributed among old documentation, CPAN modules, build systems, archived projects, present-day tools, mailing-list discussions, source repositories, and hard-won experience.

The Perl Lazarus Project workflow does not attempt to hide these tools behind an enormous new integrated development environment. Its first objective is more modest and, for the present need, more useful: identify a modern combination which works, explain what each part contributes, and document a journey which another Perl programmer can repeat.

The resulting workshop consists principally of:

• Strawberry Perl;
• wxWidgets;
• Alien::wxWidgets;
• wxPerl;
• wxGlade;
• MSYS2, vim, and Git;
• PAR-based packaging tools;
• DLL-discovery tools;
• Inno Setup;
• and a separate clean Windows environment in which the finished work can be tested.

These tools do not all perform the same kind of work. They form layers.

Understanding those layers is more valuable than memorizing a list of commands.

A workshop, not a monolith

The practical objective of the workshop is not merely a Perl script with a window, but a complete Windows application which users can run without installing the developer's toolchain.

The Free Pascal Lazarus IDE provides part of the inspiration for the Perl Lazarus Project because it presents application development as a coherent activity.

A Lazarus programmer can install an environment, create a project, place controls on a form, connect those controls to code, compile the application, and begin distributing the result. Around that process has grown a productive community of component authors, application developers, teachers, consultants, publishers, support providers, and specialist toolmakers.

This is more significant than the presence of any one editor or form designer.

The Lazarus and Free Pascal community demonstrates how a language community can support a practical micro-economy. The compiler may be freely available, but books still require authors. Components require maintainers. Applications require designers, testers, documenters, trainers, and support providers. Businesses and specialist communities still need programmers who understand their particular work.

Shared tools do not abolish human labor. They make new forms of labor possible.

Perl does not presently need to reproduce the entire Lazarus IDE in order to benefit from this example. The tools required for an effective Windows workshop already exist. The immediate need is to arrange them coherently.

The Perl Lazarus Workshop is therefore deliberately plural. One program supplies the Perl environment. Another supplies the graphical library. Another generates the interface code. Another provides a familiar editing shell. Several tools cooperate to construct the executable. Another creates the installer.

This arrangement may initially appear less elegant than a single commercial IDE. It also has advantages.

Each tool can be understood independently. Each may be replaced when a better tool appears. The developer is not entirely dependent upon one vendor, one file format, or one abandoned product. The workflow can improve incrementally without requiring the whole workshop to be rebuilt at once.

Strawberry Perl: the foundation of the Windows shop

The first layer is Strawberry Perl.

Strawberry Perl is not merely a Perl interpreter placed on Windows. It provides a native Perl distribution together with the compiler and build tools needed to install a broad range of CPAN modules, including modules containing XS or other native components.<ref>Strawberry Perl, “Releases”</ref>

That distinction matters for wxPerl.

A graphical binding to a substantial C++ library cannot be treated exactly like a small pure-Perl module. Native libraries must be built or supplied in compatible forms. Architectures must match. Compilers, DLLs, headers, and Perl configuration all matter.

Strawberry Perl gives us a practical foundation upon which that native work can occur.

It also provides tools which many Perl programmers already know how to use:

• perl;
• cpan and cpanm;
• gcc;
• gmake;
• and the normal Perl library structure.

This is one reason the Perl Lazarus Project emphasizes Strawberry Perl rather than requiring the user to construct a custom Perl environment from unrelated pieces.

The chosen environment should still be treated as a tested combination rather than an abstract promise that every release will work with every other release. The maintained installation page records current, previously tested, experimental, and archived combinations:

• a previously tested Strawberry Perl 5.40 and Wx 3.008 path;
• a newer PDL-oriented Strawberry Perl 5.42 and Wx 3.009 path;
• and older combinations which remain useful when investigating regressions.

This distinction between a known working profile and the newest possible profile is an exercise in practical wisdom.

A craftsman may experiment with newer tools. He should not confuse experimentation with a promise to users.

wxWidgets: a mature graphical foundation

The graphical foundation beneath wxPerl is wxWidgets.

wxWidgets began as an effort to create portable graphical applications for Unix and Windows and later expanded to support additional operating systems and graphical back ends.<ref>wxWidgets, “Overview”</ref> It supplies windows, dialogs, menus, controls, event handling, drawing facilities, printing support, internationalization, networking helpers, and many other facilities required by desktop applications.

Its architecture is important.

wxWidgets does not generally seek to make every application display an entirely artificial set of controls which merely resemble the host operating system. It provides ports which use the facilities of the underlying environment. On Windows, the result can behave and appear like a Windows application rather than like a foreign interface transported unchanged from another platform.

This supports two related goals.

First, the application can be familiar to the Windows user.

Second, the programmer is not necessarily imprisoned within Windows forever. wxWidgets has always been concerned with cross-platform application development, even though this series intentionally concentrates on producing and distributing the Windows version first.

wxWidgets also has a long history of associated development tools. Its own historical record includes commercial dialog and RAD products such as wxDesigner, while its broader ecosystem has included interface builders, component libraries, language bindings, books, and commercial support.<ref>wxWidgets, “History”</ref>

Readers interested in that longer story should consult Perl and wxWidgets RAD on Windows, which records earlier Perl-capable GUI builders, discontinued packaging environments, and related attempts to provide an integrated Windows application workflow.

The history matters because the Perl Lazarus Project did not arise in an empty field. It receives working pieces from earlier craftsmen, learns from abandoned paths, and attempts to preserve what can still be used.

Alien::wxWidgets: locating and describing the native library

Between wxWidgets and the Perl binding sits Alien::wxWidgets.

The name “Alien” can sound more mysterious than the function it performs. In the Perl ecosystem, an Alien distribution generally helps locate, build, or describe a non-Perl library needed by Perl modules.

In this workshop, Alien::wxWidgets provides the bridge between the native wxWidgets installation and the build of wxPerl. It records the information needed to compile and link the Perl binding against a suitable wxWidgets library.

This layer is one reason version combinations matter.

The relevant versions of:

• Strawberry Perl;
• its compiler and runtime;
• wxWidgets;
• Alien::wxWidgets;
• and Wx

must agree sufficiently for the build to complete and the resulting programs to run.

The installation script being developed for the Perl Lazarus Project exists to make this sequence repeatable. It does not abolish the need to understand the sequence.

A good installation script should reveal:

1. which version is being installed;
2. where it was obtained;
3. which command is being run;
4. where its output is logged;
5. whether the stage succeeded;
6. and how the result can be verified.

Automation is valuable when it preserves successful labor and allows another person to reproduce it. It becomes dangerous when it conceals the state of the workshop from the craftsman who must later repair it.

wxPerl: placing wxWidgets in Perl hands

The Perl binding itself is distributed as Wx and is commonly called wxPerl.

wxPerl allows a Perl program to create and control wxWidgets objects: applications, frames, panels, dialogs, buttons, text controls, lists, grids, notebooks, menus, status bars, timers, drawing contexts, and the many other facilities supplied by wxWidgets.

This means the Perl programmer can bring existing Perl abilities directly into an event-driven desktop application.

The database layer may still use DBI.

The web client may still use familiar HTTP and JSON modules.

The parser may still be the parser already tested in a command-line program or server process.

The validation rules may still live in ordinary Perl modules.

wxPerl does not require the craftsman to abandon the language in which the underlying work is already expressed. It gives that work a graphical point of contact with the user.

The renewed ability to install and build wxPerl on current Windows environments owes much to the wxPerl revival work led by Johan Vromans and assisted by others who tested, corrected, and documented the modern build path.<ref>Johan Vromans, “wxPerl Revival”</ref>

The Perl Lazarus Project builds on that labor. It is not a claim to have independently recreated wxPerl. It is an effort to carry the revived binding further into a repeatable development, packaging, and distribution practice.

The first verification after installation should therefore be visible and concrete. Wx::Demo provides examples of many available controls and facilities, while a minimal application verifies that Perl can create a frame and enter the wxWidgets event loop.

The third essay, Raising a Working wxPerl Shop on Windows, will perform that verification in detail.

wxGlade: visual design which emits Perl

wxGlade is written using wxPython, but it can save the interface design as XML and emit Perl source code for a wxPerl application.

wxPerl gives the programmer access to the graphical library, but constructing every interface entirely by hand can involve a large amount of mechanical work.

Controls must be created, placed in sizers, connected to parent windows, assigned properties, and adjusted repeatedly as the layout develops.

wxGlade provides a visual design environment for wxWidgets applications. It is written using wxPython, but this does not limit it to Python output. It can generate Python, C++, Perl, Lisp, and XRC.<ref>wxGlade, project overview</ref>

For the Perl Lazarus Workshop, the critical fact is simple:

wxGlade emits Perl.

The craftsman can arrange a window visually, save the wxGlade project as a .wxg XML file, and generate a Perl source file containing the corresponding wxPerl classes.

This makes possible a RAD-like cycle:

1. Design or revise the interface in wxGlade.
2. Save the .wxg project.
3. Generate Perl.
4. Inspect the emitted changes.
5. Add or revise application behavior.
6. Run the program with Strawberry Perl.
7. Return to wxGlade when the visual design changes.

The wxPerl and wxGlade template repository contains example interfaces intended as starting points for this process. The templates include familiar window patterns and historical interface recreations which can be opened in wxGlade, examined, changed, and emitted as Perl.

AI tools have also been effective in producing first-draft wxGlade XML files from natural-language descriptions. Those drafts are not final designs. They are materials brought into the workshop.

The proper process remains human:

1. describe the intended interface;
2. generate or obtain a first-draft .wxg file;
3. open it in wxGlade;
4. inspect the hierarchy and properties;
5. correct the layout;
6. emit Perl;
7. wire the application behavior;
8. review the code;
9. and test the result.

AI may accelerate the preparation of material. It does not determine whether the interface serves the user, whether generated code is safe, or whether the application fulfills its promises.

The craftsman remains responsible.

Readers who need ideas for first projects may consult GUI ideas for use with wxGlade.

MSYS2, vim, and Git: recovering a familiar working rhythm

A Windows application should be built and tested against Strawberry Perl, but the craftsman does not need to abandon a familiar Unix-like editing workflow.

MSYS2 supplies a Unix-like command-line environment and a package manager for Windows.<ref>MSYS2, “What is MSYS2?”</ref> Within its terminal, the programmer can install vim and Git:

pacman -S vim git

This creates a productive division of labor.

The MSYS2 terminal can be used for:

• editing with vim;
• reviewing diffs;
• committing changes;
• managing branches;
• using SSH keys;
• navigating the project with familiar shell tools;
• and performing the normal source-control work of a Unix-oriented Perl programmer.

The Strawberry Perl terminal should be used for:

• installing Perl modules;
• running the wxPerl application;
• executing Perl-oriented build commands;
• creating the executable;
• and verifying behavior against the actual Perl environment intended by the project.

This separation is not merely a personal preference. Installing Git and related packages in MSYS2 may also install an MSYS2 Perl. Running the application from that shell without checking the active PATH can therefore invoke a different Perl than the Strawberry Perl for which wxPerl was built.

The programmer should know which Perl is active.

A workshop may contain two hammers. The craftsman must still know which one he has picked up.

Git is particularly important when generated code is involved. wxGlade can preserve user code when configured properly, but configuration mistakes and generation changes can still damage handwritten work. A clean commit before generation gives the programmer a truthful record of what changed and a practical way to recover.

The detailed edit–emit–wire–run workflow belongs to the next essay. Here it is enough to recognize that MSYS2 is not replacing Strawberry Perl. It restores a familiar editing and revision rhythm around it.

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:

• PAR::Packer;
• Wx::Perl::Packager, which provides wxpar;
• and App::PP::Autolink, which provides pp_autolink.

A minimal wxPerl packing command may look simple:

wxpar my-application.pl -o my-application.exe

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 pp_autolink 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:

A dependency which is invisible to the developer is not invisible to the user's computer.

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

The current executable-building notes preserve this still-developing body of experience, including special cases involving HTTPS and Net::SSLeay.

Martha: assistance at the difficult boundary

The tool named Martha belongs near the far end of the workshop, not at its foundation.

Martha does not replace Strawberry Perl, wxPerl, wxGlade, PAR, or Inno Setup. It is a wxPerl application created to assist with the difficult transition from a working Perl program to a package which can be installed and tested.

Its present work includes assistance with:

• discovering required DLLs;
• generating a Makefile based on wxpar;
• allowing that Makefile to be reviewed and adjusted;
• running the executable build;
• generating an Inno Setup configuration;
• building the installer;
• and testing the resulting stages.

The name is related to Lazarus, but Martha's role is deliberately practical. The Perl Lazarus Project describes the larger revival and workflow. Martha helps with some of the work which is repetitive, error-prone, and easy to perform inconsistently.

The important principle is that the helper should expose the process rather than make it unknowable. The programmer should be able to inspect the generated Makefile, see the DLL paths, read the Inno Setup script, and reproduce the command outside the GUI.

A good tool assists judgment. It does not demand the surrender of judgment.

For current details, see Martha's role in the documented workflow.

Inno Setup: placing the work into the user's hands

The final major tool in the workshop is Inno Setup.

A Windows executable can sometimes be distributed as a portable file, but ordinary Windows users commonly expect an installer. The installer can:

• place program files in an appropriate directory;
• create a Start menu entry;
• create an optional desktop shortcut;
• register an uninstaller;
• preserve or update configuration;
• install additional resources;
• record version information;
• and provide a familiar route for upgrades and removal.

Inno Setup has existed since 1997 and provides a mature scriptable installer system for Windows.<ref>JRSoftware, “What is Inno Setup?”</ref>

It also offers a good example of a tool which empowers apprentices, hobbyists, nonprofits, and small developers while reasonably asking commercial users to support the human labor behind it.

The Inno Setup authors request that commercial users purchase a commercial license.<ref>JRSoftware, “Inno Setup Commercial Licenses”</ref> The request should be respected.

A Perl craftsman who expects users to compensate his own labor should not treat the labor of toolmakers as though it appeared without cost or obligation.

The license is not merely an administrative detail. It is part of a just relationship among craftsmen.

Inno Setup lowers the barrier to professional Windows distribution. It allows a small developer to offer an installation experience which might otherwise require a substantial commercial packaging product or a large amount of custom engineering. When that tool contributes to commercial income, purchasing the requested license is an orderly acknowledgment of the value received.

The installer itself must also respect the user.

It should not request administrative privileges without need. It should not overwrite user-created data carelessly. It should not make removal intentionally difficult. It should not hide unrelated software in the package. It should explain what it is installing and preserve what the user has created.

The installer is not wrapping placed around the “real application.”

For the user, installation is the beginning of the application.

The living workshop and the written recipe

The exact working version combination will change.

Strawberry Perl will release new builds. wxWidgets will advance. Alien::wxWidgets and Wx will be updated. wxGlade will correct problems and add features. Packaging tools will discover new edge cases. Windows will alter security behavior.

A book or essay cannot freeze the workshop forever.

This is why the series and the technical wiki serve different but complementary purposes.

The essays explain:

• why the tools were selected;
• how the layers relate;
• what kind of work each tool performs;
• and what virtues should govern their use.

The living installation page records:

• current download links;
• tested version combinations;
• experimental combinations;
• archived combinations;
• command lines;
• known failures;
• and corrections discovered through practice.

The craftsman should consult both.

A static essay without maintained instructions may become historically interesting but practically useless.

A list of commands without an explanation of the workshop may work once while leaving the programmer unable to understand or repair it.

Tradition requires both inherited wisdom and living application.

The craft and the virtue

This stage of the journey is governed especially by practical wisdom, gratitude, justice, and humility.

Practical wisdom asks what each tool is for.

It prevents the programmer from selecting software merely because it is fashionable, entirely written in a preferred language, or advertised as capable of doing everything.

Gratitude recognizes that the workshop is inherited.

God is the source of creation, intelligence, talent, and opportunity. The programmer receives not only his own abilities, but also a world of prior human labor: operating systems, compilers, libraries, modules, editors, books, standards, and examples.

“For wisdom is better than all the most precious things: and whatsoever may be desired cannot be compared to it.”
— Proverbs 8:11, Douay-Rheims

Justice gives the human makers of those tools what is due to them.

That may include:

• obeying licenses;
• preserving notices;
• paying a reasonable commercial fee;
• reporting defects honestly;
• acknowledging authors;
• contributing corrections;
• supporting maintainers;
• or teaching another person what one has learned.

Humility acknowledges that no one programmer created the entire workshop.

The experienced Perl programmer may know far more about databases or server operations than the author of a GUI builder. The GUI-tool author may know far more about layout engines and code generation. The installer author may understand Windows installation behavior which the application programmer has never had to consider.

The guild-minded craftsman does not resent this dependence. Human beings are made to receive from and contribute to one another.

The tools themselves must remain properly ordered.

Strawberry Perl serves the Perl programmer.

wxWidgets serves the graphical application.

wxGlade serves the designer.

MSYS2 and vim serve the editing process.

Git serves truthful revision and recovery.

PAR serves distribution.

Inno Setup serves installation.

AI may assist preparation, explanation, and first drafts.

None of them is the master.

The human craftsman remains responsible for choosing the purpose, judging the result, keeping promises, protecting the user, and directing the work toward the good.

At the workbench: draw your workshop map

Before installing the full stack, prepare a workshop inventory.

The Perl Lazarus Workshop

Layer	Selected tool	Work performed	Verification
Perl environment	Strawberry Perl	Runs Perl and supplies native build tools	Confirm the intended perl.exe, architecture, and compiler
Native GUI library	wxWidgets	Supplies windows, controls, events, and platform integration	Confirm the wxWidgets version used by wxPerl
Native-library bridge	Alien::wxWidgets	Describes or supplies the wxWidgets build used by Perl	Query the installed module version and build configuration
Perl GUI binding	Wx / wxPerl	Makes wxWidgets available to Perl	Run a minimal frame and Wx::Demo
Visual designer	wxGlade	Saves the visual design and emits Perl or XRC	Generate and run a small Perl interface
Editing environment	MSYS2 and vim	Supplies a familiar Unix-like editing shell	Confirm vim and the project paths
Revision control	Git	Preserves history, diffs, and recoverable checkpoints	Create a repository and commit the generated project
Executable packaging	PAR, wxpar, and pp_autolink	Packages Perl and discovers native dependencies	Run the EXE outside the Strawberry Perl terminal
Installer	Inno Setup	Produces the Windows installation experience	Install, launch, upgrade, and uninstall on a clean machine
Independent test bench	Clean Windows virtual machine or physical system	Reveals dependencies accidentally supplied by the workshop	Test without Strawberry Perl or the development tools installed

For each tool, answer:

1. What exact task does it perform?
2. Which other layer does it depend upon?
3. Which version has actually been tested?
4. How will success be verified?
5. Where will installation and build logs be kept?
6. What license governs its use?
7. What labor and knowledge did its authors contribute?
8. What would happen to the workflow if the tool disappeared?
9. Is the project data stored in an open or inspectable format?
10. Can the important build steps be reproduced without a graphical helper?

The purpose is not to produce paperwork for its own sake.

The map helps the craftsman understand his shop before something breaks.

Continue the journey

The next essay, Raising a Working wxPerl Shop on Windows, will assemble this workshop in practice.

It will cover:

• selecting a tested Strawberry Perl profile;
• using the Perl Lazarus installation BAT file;
• preserving installation logs;
• verifying Alien::wxWidgets and Wx;
• running Wx::Demo;
• installing and launching wxGlade;
• configuring MSYS2, vim, and Git;
• generating the first Perl GUI;
• wiring an event;
• running it under Strawberry Perl;
• and committing the result.

At the end of that essay, the reader should possess more than a collection of installed programs.

He should possess a working shop, a generated wxPerl application, a known active Perl environment, and the beginning of a repeatable craft.

<references />

Previous essay: The Perl Craftsman Returns to the Windows Desktop

Series: Essays about The Virtuous Perl Programmer

Next essay: Raising a Working wxPerl Shop on Windows