in reply to Module::Build and the PPM

Random comments in no particular order...


On the PPM front all Module::Build did was provide a way of automating the creation of a PPM distribution. Something that ExtUtils::MakeMaker and other tools already support to different extents.

The only additional things that M::B's ./Build ppmdist does over EU::MM's make ppd is automate the creation of the package archive, and add it to the codebase tag of the PPD file.

I agree with the other people who have already mentioned that the basic problem is with people uploading package archives to CPAN. This isn't M::B's fault. M::B doesn't support uploading PPM distributions to CPAN, or advocate it in any way. Neither does EU::MM. Indeed I don't know of anybody advocating the upload of package archives to CPAN.

I agree that using a PPM- prefix to differentiate a PPM package archive from a normal distribution was a mistake since it can be easily be confused with a normal module distribution with a PPM prefix. As soon as this was pointed out to Ken he said he's willing to make a patch. This, in my experience, is Ken's usual reaction to bug reports.


I think standard platform-specific package archive mirrors would be a nice idea. They would save a lot of time for those of us unfortunate enough to have to deal with platforms that don't come with build tools by default.

However IMHO they don't currently belong on CPAN, which has no infrastructure to support them in a useful way.


EU::MM is not going away. None of the M::B developers think EU::MM is going away. To the best of my knowledge nobody has said that EU::MM will be removed from core perl. M::B is an alternative (and a good one in my opinion), but if you don't want to package your modules with it then don't use it. EU::MM will be around for as long as Perl is around.


In my opinion the M::B folk are not pushing people away from using the Module::Build::Compat layer.

The three different Module::Build::Compat scenarios are, I believe, described fairly in the Module::Build::Compat documentation.

In the documentation Ken expresses his personal preference for the no Makefile.PL option. Ken's preference is not my preference. Taking a look at the M::B distributions on CPAN the vast majority of people who create packages with M::B also have a different preference from Ken. I still fail to see the harm in Ken expressing his personal preference. "I prefer" is a very different statement from "The preferred". The downside in choosing this option is clearly described.

(In fact Ken has now said he'll be removing the text expressing his preference.)

I also believe the default value of create_makefile_pl is correct. CPANPLUS already supports calling ./Build instead of make. I imagine that CPAN will be patched to do the same by the time that 5.10 arrives. In the medium-to-long term the compatability layer won't be needed for CPAN(PLUS) installs. In the short term people making distributions can easily generate appropriate Makefile.PL files automatically.

Looking at all the modules on CPAN now using M::B generated Makefile.PL files I think the rumours of M::B breaking CPAN are greatly exaggerated.


Some people have apparently had bad experiences with M::B distributions. To supply an additional data point I have not.

I've started looking at M::B seriously a bit under a year ago as various EU::MM installs were causing me severe maintenance and cross-platform problems. I now use it for all of my personal in-house projects, for all of my client work and for one of my CPAN modules (and I'll probably add it to the others when the Spare Time Fairy next visits.)

I've found it far easier to develop with then EU::MM, and have yet to receive a single complaint about any of my M::B distributions on any platform (including Windows). I wish I could say the same about some EU::MM based distributions.

Other Perl developers I know have had similar experiences.

There are certainly areas where M::B can be improved. However in my opinion it is ready for real world usage now and I would have no hesitation in recommending it to others.

I doubt that there would be as many M::B based distributions on CPAN if it did nothing but bring in a stream of bug reports, abuse and broken CPAN builds.


Some people have apparently had bad experiences with M::B developers. To supply an additional data point I have not.

I'm certainly not "widely known in the community". Only three CPAN modules to my name and I've never been to a Perl conference or a Perl Mongers meeting in my life. I'm Just Another Perl Hacker :-)

Despite this poor standing my comments and questions have always been answered quickly, accurately and politely by Ken and others.

I have not encountered any excessive hubris on the part of the developers, and they have always seemed positively eager to accept patches from others and get M::B working on as many platforms as possible. I've never seen bug reports being ignored.

There's an archive of the M::B e-mail list available on gmane for those cannot stomach the ghastly sourceforge mail archives. I would encourage people to take a look at them and judge for themselves.

I would actively encourage users who are encountering problems with M::B distributions to mail the list so the bugs can be fixed.