in reply to Updating distributions with Module::Build, Module::Starter, and PPM::Make

If you have no reason to switch an existing distribution to Module::Build, don't. If you feel you must, go ahead and include a fully functional Makefile.PL (not a "compatibility" one depending on Module::Build). Not sure what you mean about ActiveState repositories not being the pillar of reliability, but having your module's Makefile.PL depend on Module::Build is breaking backward compatibility, especially for ActiveState users. And I don't think putting ppd's on CPAN is a good enough substitute to making sure that you follow existing practices so that ActiveState can build one for you.
  • Comment on Re: Updating distributions with Module::Build, Module::Starter, and PPM::Make

Replies are listed 'Best First'.
Re^2: Updating distributions with Module::Build, Module::Starter, and PPM::Make
by jacques (Priest) on Aug 26, 2004 at 13:10 UTC
    If you feel you must, go ahead and include a fully functional Makefile.PL (not a "compatibility" one depending on Module::Build).

    Is there something wrong with the one that M::B generates for you? I guess I could use Module::Starter to generate a Makefile.PL with E::MM and a Build.PL with M::B.

      It's a little complicated; basically, in some ways, M::B is a step backwards, not a step forwards.

      Under EU::MM, to determine dependencies, you run Makefile.PL, which is allowed to tailor a list of dependencies specific to that particular installation, then read the dependencies from the "# PREREQ_PM" line in the generated Makefile.

      Under M::B, AIUI, dependencies are hardcoded in META.yml (though it does have the nice distinction between requires: and build_requires:).

      ActiveState seems to make a real attempt to validate the dependencies by running Makefile.PL in a clean environment, adding any resulting dependencies, then doing the make. But Makefile.PL's built with Module::Build::Compat's small or passthrough options require Module::Build to be installed or installable to work at a point where in the EU::MM universe, dependency information isn't yet available. You can see a passthrough Makefile.PL in action here.

      Module::Build::Compat's traditional option will work, but that won't do everything Build.PL can, so I'm not sure I see the point in not just staying with EU::MM (especially for existing modules).

      An additional note: even if META.yml were checked before running Makefile.PL, in the examples I've seen, Module::Build isn't listed as a dependency there even though it is required for the build.

        Under M::B, AIUI, dependencies are hardcoded in META.yml

        This is incorrect.

        M::B describes dependencies in its Build.PL just like EU::MM describes its dependences in Makefile.PL. The META.yml is generated from this description (as, indeed, it is with the latest EU::MM).

        An additional note: even if META.yml were checked before running Makefile.PL, in the examples I've seen, Module::Build isn't listed as a dependency there even though it is required for the build.

        Just as EU::MM isn't included in the META.yml files that EU::MM generates.

        Am I misguided to want to include a Build.PL for people using M::B instead of make to install modules?

        I know that most people still use make but I thought it would be nice to also include a Build.PL in the distribution.