Lately, I've decided to take on my long-standing frustration with getting CPANPLUS and CPANPLUS::Dist::Build to upgrade Module::Build. Thanks to some help from Jos Boumans, Chris "BinGOs" Williams and Eric Wilhelm, I think these hairy yaks are finally getting shaved.
Step 1: Module::Build 0.31_03 has just been released. It contains some workarounds that should allow existing versions of CPANPLUS::Dist::Build to upgrade Module::Build.<\p>
Step 2: BinGOs is working on an alpha of CPANPLUS::Dist::Build that will no longer try to use the Module::Build API directly, but will interact with Build.PL and Build through subprocesses using IPC::Cmd.[1] This will also mean bumping up the Module::Build version prerequisite, which will actually work, thanks to Step 1.<\p>
Step 3: After a period of testing, I hope to bump these from alphas to full releases and also roll both into bleadperl in time for 5.10.1.<\p>
If all goes well, we should finally be at a point where modules can just specify 'configure_requires' on a recent version of Module::Build and -- assuming a recent enough CPAN.pm or CPANPLUS -- things should just work.<\p>
I'm also looking into porting code from TAP::Parser::Iterator::Process into IPC::Cmd that will enable it to capture output buffers from interactive programs on Win32. This -- along with Step 2 -- will make the output from Build.PL and 'Build test' available for CPAN Testers reports on all major platforms, which is a common complaint today about CPANPLUS-based reports for modules with Build.PL
-- dagolden<\p>
[1] Why avoid the Module::Build API? The issue is that Build.PL expects to be able to create a Module::Build object from an arbitrary class. In this case of Module::Build itself, it wants to use the new version in 'lib' to build and install itself (just like ExtUtils::MakeMaker does). Or any Build.PL could use a Module::Build subclass, either on the fly or bundled in the 'inc' directory. Or it could use a replacement for a Module::Build .pm file bundled into the 'inc' directory.<\p>
In a more extreme case, some future tool could use the Module::Install trick of taking over Build.PL and generating a Build program and providing a new implementation for 'Build', 'Build test', 'Build install' and so on.<\p>
In short -- a program calling Build.PL can't make any assumptions about what happens except the creation of a 'Build' program that can be executed with various actions. <\p>
Therefore, the only safe external API that installers should use is running 'perl Build.PL' and 'Build *' actions in a separate process. The Module::Build API itself should be a private one that is only used within a Build.PL or within Module::Build subclasses.<\p>
