Adam Kennedy wrote:
Hi gang
As I have pointed out a number of times in the past, Module::Build has a
major design element missing still, in that when an upgrade or
installation of Module::Build is required, it has to be done by the user
by hand, which breaks the original (working) concept of automated
recursive CPAN module installation.
See the following for the most recent iteration of this debate.
http://use.perl.org/comments.pl?sid=3177
Now, this isn't to say that Module::Build *couldn't* work with CPAN
properly, it is just that currently it *doesn't*.
This problem is becoming an increasingly significant problem now that
about 10% of CPAN has moved over to Module::Build, and it has been
merged into the core.
I unfortunately wont be attending, but I've had a few thoughts about
these and related issues, but haven't yet had a chance to pursue them.
First, META.yml should alert installers about the dependency. The
dependency on Module::Build and any specific version requirements should
be present there. It actually is there implicitly in the 'generated_by'
field, but should probably be more explicitly listed and separated from
other dependencies, I think.
builder:
name: Module::Build
version: > 0.28
features: C_support
But the current solution is to declare it in the normal 'build_requires'
field, along with sub-dependencies like ExtUtils::CBuilder for XS builds
(yes, that feels extremely sloppy).
CPAN.pm does look at META.yml for dependencies, but I'm not sure about
CPANPLUS: I haven't had a chance to look too much into its internals.
I'd personally also like to see the dependency checking code move out of
Module::Build into a separate distro. I started work on this a long
while back but was never really happy with my initial approach. This was
the CPAN::Metadata module I've mentioned on a few occasions. The idea
being that CPAN.pm, CPANPLUS, Module::Build, Module::Install,
ExtUtils::MakeMaker can all use this module to read, write, and evaluate
the dependencies and other meta information in META.yml. This includes
the distant future dynamic dependency mini-language.
I've also wondered very briefly, without having thought it through
completely, if we couldn't move some of the initial construction code
into Module/Build.pm. Basically making it a front-end loader that will
load a very very bare minimum, do some initial checks and then load or
setup autoload to do a delayed-load of the main Module::Build::Base.
This will let us have a chance to check version problems, check that the
version currently loaded is the same version that will later be
requested for the actual 'build'. This is the current problem with the
programatic interface in some circumstances where we have one script
(eg. CPANPLUS) load Module::Build:
use Module::Build; # loads installed version
my $mb = Module::Build->new_from_context;
Then the Build.PL evaluated during the call to ->new_from_context()
changes the @INC to load a different version:
use lib 'inc'; # load a special bundled version
use Module::Build;
Oops, the bundled version isn't loaded because the installed version is
already loaded!
I /think/ if we delay loading of Module::Build::Base, we can fix this
with some caveats about not invoking any instance/class methods before
the constructor has a chance to evaluate the Build.PL. Of course, this
is still limited to running one build in the current running process...
Again, I haven't completely thought this one through though.
I think these are important problems that need to be and will be
addressed, but I still wonder how many people are experiencing the
problem? I'm not trying to belittle or deny the problem. Maybe I'm just
being defensive. But I really haven't heard of but a few instances of
this occurring. I'd sincerely like to know how much impact this bug (and
I do acknowledge that it *is* a bug or at least an incomplete feature
set ;) has had on users.
This would mean we can hopefully get the solution implemented in time
for the release of 5.8.9.
Module::Build will not be in core until 5.10.
Regards,
Randy.
