Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Wednesday February 06, 2008
08:19 PM

Perl::Dist adds support for libexpat and XML::Parser

[ #35597 ]

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 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.


The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Are you sure it has to be a GUID? I'm not entirely sure, but I think I saw installers that just used filenames as their IDs (it was especially the case for Microsoft products, platform sdks, at least all, for example). Could you just replace special characters with '_' and use that as an ID?
    • Actually, you are probably right about the files directly.

      Unfortunately, WiX also has the concept of a "component" which is very high resolution. In the context of a typical CPAN install, every module in the dependency chain would need to be a component.

  • 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.

    Actually, it's enough if the .dll file resides in the same directory as the executable. That's also the preferred location if you distribute application specific .dlls and the first location Windows looks for .dlls to be loaded. Also, that's the same location the perl58.dll lives. $ENV{PATH} comes into play later.

    • Thanks for the tip.

      At least that leaves the option open to remove PATH from the environment in some cases.