in reply to Re^2: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker
in thread Clean smoke-test install for Inline based modules using Inline::MakeMaker

Yes, that's the only reason. Perhaps it's not a very good reason, as a warning wouldn't cause an install failure anyway, right? Might not be worth forcing people to upgrade EU::MM just to squelch a warning.

However, it would be worth mentioning in the POD for Inline that the CONFIGURE_REQUIRES directive requires that the person creating the distribution have EU::MM version 6.56 (or whatever it was) installed on his system.

Opinions?


Dave

  • Comment on Re^3: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker

Replies are listed 'Best First'.
Re^4: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker
by syphilis (Archbishop) on Dec 16, 2011 at 02:03 UTC
    Opinions?

    I think we could recommend that CONFIGURE_REQUIRES include EU::MM in addition to Inline::MakeMaker - but then explain why we've included EU::MM, and let people make up their own mind as to whether they wish to do the same.

    Should CONFIGURE_REQUIRES specify Inline::MakeMaker or should it specify Inline ?
    I guess it doesn't matter much (you won't get one without the other) so long as Inline gets found and installed. I'll leave that part as is unless someone wants to convince me that it should be changed to specify 'Inline'.

    Cheers,
    Rob

      It definitely should be Inline::MakeMaker. According to the docs for ExtUtils::MakeMaker, CONFIGURE_REQUIRES, BUILD_REQUIRES, etc. should point to a module, and not a distribution.

      By the way, I noticed that Inline and Inline::C are v0.48, but Inline::MakeMaker, included with that dist. is v0.45.


      Dave

        It definitely should be Inline::MakeMaker.

        Good !

        ..but Inline::MakeMaker, included with that dist. is v0.45

        Yes, I always make sure that the Inline.pm and Inline/C.pm version numbers match the version number of the Inline distro, but I haven't bothered updating the version numbers of any of the other pm files that ship with Inline. Does it matter ? (Looking back, it seems that Ingy did keep the Inline::MakeMaker version number in tune with the Inline distro number.)
        Naturally, if I ever alter Inline::MakeMaker I'd change the version number. (At least, I'd hope that I remember to do that - I see that I've altered it once already, and did bump the version number on that occasion.)

        Inline/C/ParseRecDescent.pm, Inline/C/ParseRegExp.pm and Inline/denter.pm don't even have version numbers - yet may have been modified in the past. I last made alterations to ParseRegExp.pm and ParseRecDescent.pm back in March 2010 .... didn't think to give them a version number at the time ... something to keep in mind in the future.

        In fact I could probably assign the same version number to all of the pm files that ship with Inline, if that's the expected thing to do. (It shouldn't stress me too much :-)

        Cheers,
        Rob
Re^4: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker
by GrandFather (Saint) on Dec 16, 2011 at 02:04 UTC

    I'd be inclined to put those sort of directions in a dev-readme.txt file (perhaps in the /t folder) or maybe as a "For maintainers" section in the README file rather than cluttering the POD with stuff that isn't pertinent to users.

    True laziness is hard work

      I see where you're going with that thought, and you may be right. But Inline currently does have a section entitled "Writing Modules with Inline". And it discusses the make dist topic. It's just incomplete in light of what we've been discovering the past few days. Perhaps that whole section could be split out into its own POD file similar to Inline::C-Cookbook.


      Dave