Yesterday I tried out CamelPack, Stennie's installer for ActivePerl/Dev-C++/nmake. I can understand Stennie's choice for the bulk of Dev-C++, because it comes as one package and it installs the 5 or more packages you need for MinGW, for which Stennie rightfully writes that they've truely mastered the art of homepage obfuscation.
I wish SourceForge allowed an easier, uniformized access to their downloads, instead of just via people's own HTML pages. We should eventually find a way to download the required latest packages from Current, and preferably pick a proper mirror for SourceForge.
Stennie's choice of tools to build the installer, is excellent.
Anyway, as my ActivePerl was a bit outdated, I've let it install a new version of ActivePerl... big mistake. It grabbed simply every setting related to Perl, and now PXPerl no longer worked reliably, as CPAN.pm now used ActivePerl as the perl executable, and its compiler settings for MinGW were those of Dev-C++, too. So, after my experiments were over, I simply deinstalled both, and now PXPerl is working well again. That's a detail that should be addressed at some point: many people like to have more than one perl install at their disposal.
Installing XS modules seems to work rather well but not perfectly. I've tried testing Text::CSV_XS, DBI, DBD::SQLite, and Data::Dump::Streamer (all XS modules with no external dependencies), with both PXPerl and with CamelPack. All tests succeed on both, except for one test from DBD::SQLite, test #6 from 03insert.t, that failed on CamelPack and passed on PXPerl.
Maybe PXPerl was getting in the way of CamelPack, so I dare not yet draw final conclusions, but it looks a bit to me like there may be some minor incompatibilities between MinGW's gcc and Microsoft's VC6 compiler.
To be continued. And if you feel like experimenting yourself, feedback is always welcome.
I'll eventually try out CamelPack on a computer that doesn't have PXPerl. One of these days.