Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^2: Clean smoke-test install for Inline based modules using Inline::MakeMaker

by Anonymous Monk
on Dec 14, 2011 at 19:36 UTC ( #943612=note: print w/replies, xml ) Need Help??


in reply to Re: Clean smoke-test install for Inline based modules using Inline::MakeMaker
in thread Clean smoke-test install for Inline based modules using Inline::MakeMaker

Yup, unless you have Inline::MakeMaker, none of

$ pmvers CPANPLUS CPAN CPANPLUS: 0.9111 CPAN: 1.9800

will try to install Inline::MakeMaker after Makefile.PL dies. I doubt they consult META.json (cpanm might).

So yeah, I think the inline approach is definitely the ticket :)

  • Comment on Re^2: Clean smoke-test install for Inline based modules using Inline::MakeMaker
  • Download Code

Replies are listed 'Best First'.
Re^3: Clean smoke-test install for Inline based modules using Inline::MakeMaker
by syphilis (Chancellor) on Dec 15, 2011 at 05:18 UTC
    I doubt they consult META.json

    What davido has presented here is a specific example of a more general problem.

    If a Makefile.PL contains:
    use Foo;
    how is the cpan shell then supposed to know (*before* executing that Makefile.PL) that it needs to check whether Foo.pm is installed (and immediately run off and install Foo.pm if it's not).
    I would expect that there should be *some* way of effecting this.

    Otherwise, any distro that use's a non-core module in its Makefile.PL runs the risk of being hammered in exactly the same way as davido's module.

    Cheers,
    Rob

      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.


      Dave

        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

        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 ];

      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; } }

      #!/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, ... }, )

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://943612]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2018-02-22 11:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    When it is dark outside I am happiest to see ...














    Results (291 votes). Check out past polls.

    Notices?