Eric Wilhelm wrote:
# from Ken Williams
# on Saturday 31 March 2007 08:12 am:
On Mar 31, 2007, at 6:51 AM, Adam Kennedy wrote:
It may not be your line of code that failed, but it's still your
responsibility for breaking the toolchain in your Build.PL, and
thus the bug is correctly yours.
Are we talking about the bootstrapping problem again? Do CPAN&+ not
read META.yml?
Yep, this is the bootsrapping problem again.
META.yml is only advisory, not authorative, when it comes to deps,
because of platform-specific, host-specific and a variety of other
issues that mean you can only know deps when you run code.
The main reason we can't ever default to --allow_mb_mismatch=1 is
that we don't promise binary compatibility of the _build/ directory
across releases.
So, we need to upgrade Module::Build before Build.PL runs, but don't
know what version we want until we're running Build.PL, right?
That's pretty much the problem I keep harping on about :)
The CPAN toolchain design simply does not support configure-time
dependencies.
(which is what I hope to fix with this configure_requires addition to
META.yml)
Could we solve this if Module::Build could download and install a newer
version of itself?
While very evil, this MIGHT be possible... I'm just not sure if old
versions of CPAN.pm are properly re-entrant.
How can we access the ARGV with which `perl Build.PL` was run? If we
were to exec('perl', @original_perl_args) after upgrading MB, would
that do the trick?
Yep, or system() on Win32 (it doesn't like exec)
Of course, the MB versions that don't self-upgrade wouldn't be fixed,
but perhaps we can get CPAN and CPANPLUS to depend on a new version of
MB in order to get the solution out sooner?
The correct fix is to make the toolchain support configuration-time
deps. This fixes not just M:B's problem but a WHOLE bunch of other
problems at the same time.
As a second-resort, having self-upgrading Module::Build might be possible.
Adam K
