The purpose of CONFIGURE_REQUIRES (ExtUtils::MakeMaker and Inline::MakeMaker) seems to be to get a dependency listed in the META.json and META.yml files when the author executes make dist such that the dependency is pulled in by cpan before the target system executes Makefile.PL

At least that's what I gather by reading the docs for cpan.pm and ExtUtils::MakeMaker. As has been pointed out elsewhere in this thread earlier versions of ExtUtils::MakeMaker (and probably Inline::MakeMaker) didn't support the CONFIGURE_REQUIRES directive. But my theory is that if the distribution is built with a modern version, and if the CONFIGURE_REQUIRES specifies a more modern version of *::MakeMaker, those dependencies will be pulled in ahead of the target system actually running Makefile.PL.

I believe the other mistake I was making was listing 'Inline' as the BUILD_REQUIRES dependency. I believe BUILD_REQUIRES is "too late", whereas CONFIGURE_REQURIES directs an earlier stage in the process. By re-reading the MakeMaker docs I also see that the dependency should list modules (such as Inline::MakeMaker), not distributions (such as Inline, which includes the Inline::MakeMaker module). I had thought that Inline would pull in Inline::MakeMaker. But the docs are pretty clear that the module should be listed.

I've made a new attempt for Math::Prime::FastSieve wherein I'm specifying Inline::MakeMaker 0.45 and ExtUtils::MakeMaker 6.62 as CONFIGURE_REQUIRES modules. I believe that by specifying CONFIGURE_REQUIRES when creating the distribution, and by specifying modern versions of those required modules, the cpan shell should pick up on this and upgrade those modules. The docs for cpan.pm do mention that cpan reads the META.yml file to detect dependencies.

Within a couple of days enough smoke tests should trickle in that I'll have a better idea if this fixes the issue. If not, I may have to shift gears to Module::Install, or inline Inline::MakeMaker's code into Makefile.PL. Neither of those approaches seem anywhere near optimal; Module::Install adds yet another dependency that is outside of the Inline realm, and inlining additional code into Makefile.PL is going to become a kludge.

I'll report back once I see how the smoke tests turn out. As I mentioned on the Inline mailing list, once we determine what steps are needed we'll want to get Inline's documentation updated to assist the next guy to come along.

As has been pointed out elsewhere in this thread earlier versions of ExtUtils::MakeMaker (and probably Inline::MakeMaker) didn't support the CONFIGURE_REQUIRES directive

The critical thing would be the version of the cpan module being run by the user, and the version of EU::MM that the user has installed.

Inline::MakeMaker is just the hapless module that needs to be present.
It should just ignore the CONFIGURE_REQUIRES - which should be fine. By the time we get to the stage where Inline::MakeMaker realizes it doesn't know what CONFIGURE_REQUIRES is, "CONFIGURE_REQUIRES" will already have served its purpose (if all goes as planned).

Anyway, let's see if that works.
Here's hoping :-)

Cheers,
Rob

The CONFIGURE_REQUIRES directive is only really required to be supported on the distribution author's 'machine', not on end-users' machines.

App-EUMM-Upgrade is a good tool for upgrading a Makefile.PL that produces something like this, any fancy features will be removed when it is run on the end-users' configuration.

'configure_requires' itself is documented in the CPAN::Meta::Spec. CPAN clients ( such as cpan, cpanp and cpanm ) will read any META.yml/META.json file included with a distribution and resolve any modules listed as 'configure_requires' before executing Makefile.PL/Build.PL.

Within a couple of days enough smoke tests should trickle in that I'll have a better idea if this fixes the issue.

Well, it should fix it , it does in my testing.

cpanp -u Inline::CPP Inline Math::Prime::FastSieve    --force 
cpanp -i  DAVIDO/Math-Prime-FastSieve-0.04.tar.gz
[download]

You can test before uploading for this issue with

#!/usr/bin/perl --
use strict; use warnings;
use URI::file;
my $file = q[Math-Prime-FastSieve-0.04.tar.gz];
$file = URI::file->new( $file )->abs(URI::file->cwd);
system qw[ cpanp -u Inline::CPP Inline Math::Prime::FastSieve    --for
+ce ];
system qw[ cpanp -i  ], $file , qw[ --skiptest  --no-allow_build_inter
+activity ];
[download]

Hammered? Its much ado about nothing

SmokeTesters Complain of Missing Dependencies Which a Module's Makefile.PL Requires

http://wiki.cpantesters.org/wiki/CPANAuthorNotes

#!/usr/bin/perl --
BEGIN {
    unless( eval { require Inline::MakeMaker; 1; }  ){
        warn "Warning: prerequisite Inline::MakeMaker 0 not found.\n";
        exit 0;
    }
}
[download]

#!/usr/bin/perl --
use ExtUtils::MakeMaker();
if(
    eval {
        require Inline::MakeMaker;
        1;
    }
) {
    *WriteMakefile = \Inline::MakeMaker::WriteMakefile;
} else {
    *WriteMakefile = \&ExtUtils::MakeMaker::WriteMakefile;
}


WriteMakefile(
...
    PREREQ_PM         => {
        'Inline::CPP' => 0.33,
        'Inline::MakeMaker' => 0,
        ...
    },
)
[download]

But its a whole bunch of effort to avoid some Makefile.PL boilerplate (the essence of Inline::MakeMaker), or switching to Module::Install

Hammered? Its much ado about nothing

Yeah, I feel much the same way - but I have some respect for the wishes of those who expect their modules to build straight out of the box in the cpan shell, no failures and no NA/UNKNOWN.

The problem with your BEGIN{} block is that it doesn't tell the cpan shell to fetch and install the package that contains Inline::MakeMaker. If it was *my* module, that wouldn't bother me in the slightest, but many people expect better.

The second attempt looks promising - it might even provide the desired behaviour. (Does it ? The thing is that, when it comes to finally build the module, it's Inline::MakeMaker, not ExtUtils::MakeMaker, that needs to be loaded by the Makefile.PL.)
There's actually no need to specify Inline::MakeMaker in PREREQ_PM, as installing Inline::CPP will install Inline::MakeMaker.
I think that might actually work !!

But its a whole bunch of effort to avoid ... switching to Module::Install

And well worth the effort, imo. (But, again, this is not necessarily a view shared by the perl community at large.)

Cheers,
Rob

The second attempt looks promising - it might even provide the desired behaviour. (Does it ? ...

AFAIK it should, I'm 90% that it will, but if it doesn't, this ought to fix it (should force make to rerun Makefile.PL with Inline::MakeMaker )

END {
    if( not exist $INC{'Inline/MakeMaker.pm'} ){
        $atime = $mtime = time + 10 ;
        utime $atime, $mtime, 'Makefile.PL'; 
    }
}
[download]