in reply to Clean smoke-test install for Inline based modules using Inline::MakeMaker
In Makefile.PL ensure that the following directive gets passed to WriteMakefile():
CONFIGURE_REQUIRES => { 'Inline::MakeMaker' => 0.45, 'ExtUtils::MakeMaker' => 6.62, },
This is a directive that only alters the way that make dist composes the META.yml and META.json files. In specific, those files will contain a configure_requires section. The various install tools (cpan, cpanm, and cpanp) will read the META.yml file, see what the "configure" requirements are, pull them in, and install them prior to executing Makefile.PL. At that point Makefile.PL will run cleanly as it will have access to the versions of ExtUtils::MakeMaker and Inline::MakeMaker that will allow a trouble-free install. As an added benefit, by causing EU::MM to upgrade (if necessary), the warning about not recognizing the CONFIGURE_REQUIRES directive goes away.
The directive really has no effect on the target system. All the primary effects take place at the time the distribution is composed and packed up. The fact that everything will now work on the target system is because the distribution was built in a more failsafe way.
As proof of concept refer to Math::Prime::FastSieve version 0.04. The smoke tests have begun trickling in, and with 18 of them I haven't yet seen an "UNKNOWN".
To assist the next guy who comes along the docs for Inline should probably contain the following modification in the Writing Modules with Inline section:
The following text:
Finally, you need to modify the Makefile.PL. Simply change: use ExtUtils::MakeMaker; to use Inline::MakeMaker;
Should say:
Finally, you need to make the following modifications to Makefile. +PL. Change: use ExtUtils::MakeMaker; to use Inline::MakeMaker; And add the following directive to WriteMakefile(): CONFIGURE_REQUIRES => { 'Inline::MakeMaker' => 0.45, 'ExtUtils::MakeMaker' => 6.62, },
My rationale for wanting to get a clean "one touch" install is this: If someone attempts to install a module and it fails, they may just move on to some other module, even if the one they chose initially would have been a very good choice had they gone through the extra steps of figuring out why it's not installing. I feel that part of the responsibility for quality insurance that an author takes on is that his module should install successfully using common conventions, without expecting the user to sift through a screen-full of error messages. It's sort of "putting your best foot forward."
As for "Why base a module on Inline?" Well, it's documented in the Inline POD as being a capability. There are tools such as InlineX::CPP2XS that will convert a module with Inline::CPP dependency to an XS module. But that may not exist for Java, Python, etc. So by ironing out the details, all Inline-dependency authors benefit.
On the down-side of requiring an Inline dependency in a module, there is yet another dependency for the user to deal with. Sort of like pulling in Moose for a trivial task, except the only performance penalty with Inline-based modules is paid at install time. Compiletime for code using an Inline-based module won't be impacted negatively in any measurable way. But on the other hand, making the Inline suite of tools more bullet proof could facilitate increased innovation in writing Perl extensions, as the barrier to entry is lower than writing pure XS.
But all of this is just how I rationalize the endeavor in my own mind, when the real reason is that I've been having fun with it. That's how it should be, right? :)
Dave
|
|---|