in reply to Re^3: (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

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
  • Comment on Re^4: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker

Replies are listed 'Best First'.
Re^5: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker
by davido (Cardinal) on Dec 16, 2011 at 04:18 UTC

    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

[reply]
      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
[reply]

        It's certainly not necessary for all modules in a distribution to have the same version number, but where the two modules I'm most familiar with (Inline, and Inline::C) do match, I mistakenly assumed that Inline::MakeMaker would as well, and nearly made the mistake of specifying CONFIGURE_REQUIRES => { Inline::MakeMaker => 0.49 }

        Ok, actually I did make the mistake, but the output from make was loud enough for me to realize the error before attempting to make test, and make dist. :)

        I wouldn't worry about it. Now that I know it's not just an oversight I will sleep just fine tonight.... if it weren't for the other issues (.h, no .h) I can't seem to let go of. haha


        Dave

[reply]
[d/l]
[select]

        I'd consider it in terms of release cycle. If all the modules have the same release cycle I'd be strongly inclined to use the same version number. If the release cycles for the individual modules are sensibly disjoint I'd be inclined to use different version numbers. However if the modules are related (by API definition perhaps) but may have disjoint release cycles I'd use a major.minor.point version number scheme where interface changes imply at least a matching minor version bump across the suite and point bumps for individual module releases.

        True laziness is hard work
[reply]

In Section Seekers of Perl Wisdom