running "g-cpan.pl DateTime::Format::Builder" starts installing the prerequisites okay, but it fails here: emerging DateTime-Format-Builder Calculating dependencies ...done! >>> emerge (1 of 1) dev-perl/DateTime-Format-Builder-0.7804 to / --- No package manifest found: /tmp/perl-modules_22624/dev-perl/DateTime-Format-Builder/Manifest >>> md5 src_uri ;-) DateTime-Format-Builder-0.7804.tar.gz >>> Unpacking source... >>> Unpacking DateTime-Format-Builder-0.7804.tar.gz to /var/tmp/portage/DateTime-Format-Builder-0.7804/work >>> Source unpacked. /usr/bin/perl Build.PL config=prefix=/usr core destdir=/var/tmp/portage/DateTime-Format-Builder-0.7804/image/ Too early to specify a build action 'core'. Do 'Build core' instead. Couldn't run Build.PL: Bad file descriptor at /usr/lib/perl5/vendor_perl/5.8.4/Module/Build/Compat.pm line 109. make: *** No targets specified and no makefile found. Stop. !!! ERROR: dev-perl/DateTime-Format-Builder-0.7804 failed. !!! Function perl-module_src_compile, Line 58, Exitcode 2 !!! compilation failed It looks like "Too early to specify a build action 'core'. Do 'Build core' instead." is the important line in the error. Reproducible: Always Steps to Reproduce:
I'm running into this same problem with Params::CallbackRequest. It looks like there may be a prerequisite step in the build of the module that we're skipping here, but I'll need to take another look. Keep in mind I am no Perl Guru though.. /usr/bin/perl Build.PL config=prefix=/usr core destdir=/var/tmp/portage/Params-CallbackRequest-1.13/image/ Too early to specify a build action 'core'. Do 'Build core' instead. Couldn't run Build.PL: Bad file descriptor at /usr/lib/perl5/vendor_perl/5.8.4/Module/Build/Compat.pm line 109.
It looks like this is caused by the use of Module::Build.. the thing I'm confused about is that CPAN::Distribution->make doesn't seem to be conscious of Module::Build modules.. so I now have to track down how these things get automagically built in CPAN before I can figure out why it's broken in g-cpan.pl foo.
Build.PL for Module::Build is called via stub Makefile.PL.. The problem is in the Module::Build::Compat wrapper that maps Makefile.PL configuration variables into its own format.. in particular, there's a bug with the INSTALLDIRS map that can be fixed by changing: INSTALLDIRS => sub {local $_ = shift; 'installdirs=' . /^perl$/ ? 'core' : $_ } To: INSTALLDIRS => sub {local $_ = shift; 'installdirs=' . (/^perl$/ ? 'core' : $_) } in /usr/lib/perl5/vendor_perl/5.8.4/Module/Build/Compat.pm I'll report this upstream (the problem is only with a directive of INSTALLDIRS=perl) to the CPAN module maintainer. In the meantime, if you make the change above it should resolve the issue.
Awesome, that fixed it, thanks. I checked a BSD box that happened to have p5-Module-Build-0.25.02 and it looks like the fix already exists in that version.
Alright, after working with this a bit more, it looks like Module::Build doesn't handle paths properly with the arguments g-cpan.pl (and CPAN in general) hand into the Makefile.PL. Module::Build version .25 does indeed fix this problem, but it raises another issue with the use of prefix=/usr being handed in.. In fact, it causes the build to die once again do to an attempt to catch people handing in a PREFIX on the build command line. The good news is that Module::Build uses the site Config.pm to pull paths if no PREFIX is handed in, so simply removing the catch for PREFIX in Module::Build::Compat seems to resolve that issue. What a headache..There's already an ebuild for moduld-build 0.25, it just hasn't been marked stable as of yet. You can patch that after installation to resolve the PREFIX issue by editing: /usr/lib/perl5/vendor_perl/5.8.4/Module/Build/Compat.pm and deleting the two lines: PREFIX => sub {die "Sorry, PREFIX is not supported. See the Module::Build\n". "documentation for 'destdir' or 'install_base' instead.\n"}, Mayhaps I should open this as another bug with the appropriate details for Module::Build.. I don't think we'll be able to get the upstream to patch as their build scripts aren't built for this type of automation, it appears.
Fixed in the next version, along with a change in the eclass to automagically handle Module::Build applications if needed.
