but it cannot be automatically built and installed using cpan

That's a valid indictment of the way CPAN.pm works. It's not *just* XML::Parser that's subjected to this ... if I understand correctly, *any* module that needs to be built against a 3rd party library cannot be built using CPAN.pm iff the 3rd party library is in a location where perl is unable to find it (by default). On *nix, this is generally not a problem as the 3rd party libraries are normally installed in a location where perl *does* find them by default. But on Windows I, for one, build my 3rd party libraries using the MSYS shell, and install them into (what the MSYS shell regards as) /usr/local ... and perl does not find that "/usr/local" directory by default.

Actually, I think (based upon some recent private correspondence from adamk) that XML::Parser is a little special in that, even if the expat library is placed in a location where perl can find it by default, XML::Parser *still* won't build on Windows using CPAN.pm ... but complain about that to the XML::Parser author.

I'm sure CPAN.pm is very good, but I personally find it detestable (primarily because it ignores any instructions that have been given in the README) and don't use it. I tend therefore to also avoid modules such as Net::SSH::Perl which assume (via their copious use of other modules) that CPAN.pm is being deployed.

In short, since I don't use CPAN.pm (and since I'm not the author of XML::Parser) I don't really care about the caviats regarding the building of XML::Parser on Windows using CPAN.pm. I've personally found the building of XML::Parser to be quite straightforward (once I knew how :-)

However, I probably *will* get back to looking at why that disparity exists between Strawberry Perl and my own MinGW-built perl when building your patched XML-Parser-2.36. Curiosity is sure to get the better of me in the end :-)

Cheers,
Rob