I just spent a while on #toolchain with kane and ewilhelm trying to
understand why CPANPLUS::Dist::Build has problems building and testing
Module::Build. That's grist for a longer thread, but in the process, I had
a brainstorm for how to get M::B to work around the problem. It turns out
to be a two-line patch in the M::B svn trunk (attached) to just have M::B
allow itself and its tests to have M::B mismatches. I created a dist
tarball, injected it into my minicpan and used CPANPLUS successfully to
build and test it. (It also tested correctly on CPAN.pm.)
So -- I'm looking for reasons why this shouldn't just get added into trunk.
Yes, it's a hack, but until CPANPLUS::Dist::Build stops using
new_from_context, it's a reasonable workaround.
Longer term -- if we either implement an API to examine prereqs in _build or
if we just move to MYMETA.yml support, then C::D::Build won't need to call
new_from_context at all, but we still need an easier way to get people to
upgrade Module::Build than to have to manually force install it. I think
this hack does it.
-- David
=== Build.PL
==================================================================
--- Build.PL (revision 2489)
+++ Build.PL (local)
@@ -59,6 +59,7 @@
# overwrite the M::B that shipped in core
installdirs => ($] >= 5.009004 ? 'core' : 'site'),
+ allow_mb_mismatch => 1,
auto_features => {
YAML_support => {
=== t/lib/DistGen.pm
==================================================================
--- t/lib/DistGen.pm (revision 2489)
+++ t/lib/DistGen.pm (local)
@@ -405,6 +405,7 @@
use strict;
use Module::Build;
my \$b = Module::Build->new(
+ allow_mb_mismatch => 1,
$args
);
\$b->create_build_script();
