|Problems? Is your data what you think it is?|
Re^4: Clean smoke-test install for Inline based modules using Inline::MakeMakerby davido (Archbishop)
|on Dec 15, 2011 at 06:23 UTC||Need Help??|
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.