in reply to Re: Re: Re: Re: Module::Build and the PPM
in thread Module::Build and the PPM

Why is this option not simply the default then?

That way, Module::Build could have transparently replaced ExtUtils::MakeMaker without any other interference.

For something that wants to replace an existing module, I find the lack of migration paths a major deficiency. And since I found that Module::Build doesn't scratch the itches I have with ExtUtils::MakeMaker, I'm not likely to move the rest of my modules over to it.

  • Comment on Re: Re: Re: Re: Re: Module::Build and the PPM

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Module::Build and the PPM
by autarch (Hermit) on May 19, 2004 at 16:25 UTC

    Why is this option not simply the default then?

    I can't say for sure, but I'm guessing because Ken wants people to think about how they want to do this. The passthrough option seems to work reasonably well, but it is doing pretty funky stuff under the hood. The other methods that use a Makefile.PL also have their drawbacks, so it's really up to each developer to decide how they want to handle this.

    For something that wants to replace an existing module, I find the lack of migration paths a major deficiency.

    Somebody else has created a Makefile.PL => Build.PL converter tat works for simple Makefile.PL scripts. If you're doing something complex in your Makefile.PL, there's obviously no way to automate the conversion.

      I can't say for sure, but I'm guessing because Ken wants people to think about how they want to do this. The passthrough option seems to work reasonably well, but it is doing pretty funky stuff under the hood. The other methods that use a Makefile.PL also have their drawbacks, so it's really up to each developer to decide how they want to handle this.

      As corion said, the problem here is that a module like M::B shouldnt make each developer decide how to handle this. It should simply default to the solution that breaks the least things and provide an opt out for power users. Breaking CPAN by default is just plain wrong, wrong, wrong.

      Somebody else has created a Makefile.PL => Build.PL converter tat works for simple Makefile.PL scripts.

      So wait, if I choose to convert to using Module::Build not only do I inconvenience all of my users who dont have Module::Build, I also lock out the ones who can't get it to work, and as an added bonus get to spend hours converting non trivial Makefile.Pl's over to Build.Pl framework? Gee sign me up.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi


        So wait, if I choose to convert to using Module::Build not only do I inconvenience all of my users who dont have Module::Build, I also lock out the ones who can't get it to work, and as an added bonus get to spend hours converting non trivial Makefile.Pl's over to Build.Pl framework? Gee sign me up.

        So don't freaking use it. Sheesh, no one has ever said "run out and convert all your existing modules, especially the ones that have heavily customized Makefile.PL files".

        OTOH, if you're writing a new module, or looking into adding custom bits to a Makefile.PL for an existing module, then Module::Build is probably worth looking at, as creating a customized build/install process with it is much, much easier than with EU::MM. I've done both, so I'm in a good position to know.