http://www.perlmonks.org?node_id=414963


in reply to Re^2: On packaging modules (time to fix the big Module::Build issues)
in thread On packaging modules

Now if we can get Module::Build to include a pass-through Makefile.PL by default

No, Module::Build should not produce a Makefile.PL by default. MakeMaker can't do all the things Module::Build can do and vice-versa. The generated Makefile.PL will not contain any extra logic in the Build.PL, such as asking the user configuration questions or sniffing the environment.

But most importantly, MAKEMAKER HAS TO DIE!

Having Module::Build attempt to be backward compatible with MakeMaker is a temporary solution while MB firms up and CPAN utilities catch up with it (CPANPLUS 0.50 finally handles MB pretty good). It has to take over fully from MakeMaker. Ubiquitous Makefile.PLs just delay this.

I'm assuming that the major Win32-related issues with Module::Build have been addressed.

Something projects like Module::Build and MakeMaker are always short on are Windows developers and Windows machines to check stuff out on. I can almost never find someone to check out MakeMaker releases, its actually easier for me to find VMS folks than Windows folks. And at the very least I can log into a remote VMS machine and test things out. I don't have any such thing for Windows (VNC does not count, its not multi-user AFAIK).

This is not a dig at Windows, its a problem statement. If you know of a way we can log into a remote Windows server to test things out, let us know. Or if you know some font of competant Windows Perl developers send them over to module-build-general@lists.sf.net and makemaker@perl.org.

There's a bunch of open Win32 bugs on rt.cpan.org. Have at 'em.

The second issue will probably be getting Module::Build into core Perl.

MB is slated to go into 5.10 along with CPANPLUS.

-- Michael G Schwern

Replies are listed 'Best First'.
Re^4: On packaging modules (sigh)
by tye (Sage) on Dec 15, 2004 at 14:09 UTC

    If you want MakeMaker to die, then you need to get Module::Build accepted. The biggest roadblock to getting Module::Build accepted right now is that it breaks things. Backward compatability with MakeMaker in the short term will thus make the death of MakeMaker happen faster rather than slower.

    - tye        

Re^4: On packaging modules (time to fix the big Module::Build issues)
by Corion (Patriarch) on Dec 15, 2004 at 09:29 UTC
    MAKEMAKER HAS TO DIE!

    Just because you say so doesn't make it necessarily so. There is one central rule to unhappy customers:

    Customers don't complain, customers switch

    and, in the case of Module::Build, the customers won't switch, they will stay with the proven solution that works.

    I am cpantesting Module::Build and have shaken out some bugs tat were present even in the unixish versions - I'm not really convinced that Module::Build is the future, even if MM::EU is doomed. For example, in the current version (0.2605), Module::Build refuses to upgrade itself unattended (should be fixed by now, as the bug has been reported). I'm not really interested in the metaphysical intricacies of building a module that builds other modules, and my involvement with Module::Build should be seen as damage control rather than active interest. If Module::Build goes into the core with 5.10 in its current state, I see a bleak future for Perl, as CPAN loses a lot of its functionality/convenience. Of course, 5.10 is far away, so the statement can still be valid, much in the same sense the Green Party long lobbied for a price of 10 DEM for the liter gasoline, and just after they dropped that point, the price of gasoline skyrocketed to now 1.2 EUR per liter and is still on the rise, wihtout any inside political intervention.

    I can set up a special automated Win32 smoketest mailaccount for you, but I won't join the MakeMaker mailing lists, as MakeMaker mostly works on Win32, and works lots better than Module::Build. I can also spend time to diagnose test failures, but I'm not really interested in actively writing code that never gets applied (like, say, for Test::Inline).

    Update: I'm a stupid moron - my patch to Test::Inline got applied about a year ago and I never noticed.

      I agree re the need for damage control, but see putting Module::Build in the core for 5.10 (and even 5.8.7) as the way to make it happen. Though schwerns recent bout of activity is even more effective.
      MAKEMAKER HAS TO DIE! Just because you say so doesn't make it necessarily so.

      Actually it kinda does. <evil grin>

      But regardless, of course the bugs have to be fixed, what do you think we have been doing? Part of what's held MB back is a lack of users and a lack of modules using it. And directly, not through a Makefile.PL compat layer. Now that CPANPLUS has Module::Build support its getting a lot more use and the bugs are getting shaken out. Of course, everybody sees this process and starts yelling in despair.

      DON'T PANIC! There's lots of time before 5.10. Just keep hammering on MB and keep fixing the bugs. And for god's sake, keep USING IT! If nobody uses it the bugs won't get found and fixed.

      MakeMaker mostly works on Win32, and works lots better than Module::Bu +ild

      Except for that whole "don't have make" thing. And the "this module extended the Makefile using non-portable make code" thing. And lemme tell ya, its a royal pain in the ass to write make portably, especially for nmake. Yuck.

      And I'm tearing out more redundant code which means I'm probably about to break stuff.

      I can set up a special automated Win32 smoketest mailaccount for you, +but I won't join the MakeMaker mailing lists, as MakeMaker mostly wor +ks on Win32

      That smoketest mail account would be useful, thank you. And yes, don't waste too much time on MakeMaker. Spend it on MB.

      20041216 Janitored by Corion: Changed PRE to CODE tags to allow wrapping

        Just keep hammering on MB and keep fixing the bugs. And for god's sake, keep USING IT! If nobody uses ot the bugs won't get found and fixed

        Which brings us back to my starting point - I'm not interested in developing a module-building module myself. M::B and EU::MM to me are two vehicles of delivering my product to my potential users. One of the two works, and the other doesn't. So common sense dicates that I use the working vehicle instead of the broken one.

        I'm in the process of digging through EU::MM myself, because I want to create an integrated Crypt::SSLeay distribution that uses the information from the current Perl instead of relying on the handmade Makefiles derived from EU::MM output, so I understand your pain, but I also wonder why schwern hasn't turned the MM::* stuff into mixin-based modules, one mixin for the make flavour, and one mixin for the OS flavour.

        I will /msg schwern the details and try to set up a wholly automated process that reduces the necessary manual steps to a minimum I hope.