use Perl

After on-again off-again attempts for at least 3 months, we've finally managed to find a combination of libexpat and XML::Parser that configures, builds and passes tests inside the Perl:Dist C/Perl build environment.

The winning combination was a Steffen Muller PAR package of libexpat that contained BOTH the static and shared .dll forms of the library, which was then tweaked to move the .dlls from the default location in c/lib to perl/bin.

The reason that the .dlls were moved to perl/bin is that by default Perl::Dist tries to only add one entry to PATH mostly for simplicity reasons, but also because the toolchain in c/bin is considered to be private to the Perl distribution, so adding c/bin to PATH is innapropriate.

Since .dll files need to be in the PATH somewhere, that leaves perl/bin as the location that shared libraries need to exist for Perl modules to find them.

(Incidentally, perl/bin is where perl588.dll lives anyways)

Support for expat/XML::Parser is currently hand-hacked into Vanilla, but will shortly move into the Perl::Dist core as ->install_expat (for the expat part).

With both the PAR and XML::Parser features green, the next step will be to get PPM support added, most likely via the core PPM.pm module, and the PAR-translation layer (that converts PPM to PAR on the fly).

In other news, I continue to investigate what it will take to convert to an .msi installer. I'm discovering all kinds of evil problems.

My favourite example so far is that every component/file in the distribution needs to be allocated a GUID that the Microsoft installer system can then track.

That itself isn't the problem.

The problem is that you need to REUSE the same GUIDs for EVERY SINGLE RELEASE of a particular named product. So every time you build an installer, you need to make use of (and update) an eternal GUID state cache that semantically understands which files live where.

This means builds are no longer able to be treated in isolated form and everything gets way more complicated.

Eeep.