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 ]

dagolden (6584)

  (email not shown publicly)
AOL IM: xdaveg (Add Buddy, Send Message)

Journal of dagolden (6584)

Sunday February 08, 2009
07:55 PM

Module::Build/CPANPLUS yak shaving

[ #38432 ]

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.

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

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

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 or CPANPLUS -- things should just work.

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

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

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.

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.

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.

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.