Not yet. Module::Build is a huge pain right now because it doesn't come standard with Perl. When it ships with perl, it will be a reasonable option, but it still irks me that it can't take the same flags (e.g. PREFIX) which we have been trying to teach to newbies without root for eons now.

Not yet. Module::Build is a huge pain right now because it doesn't come standard with Perl.

Passthrough Makefile.PLs and auto-installation have worked well in solving the installation issue for me.

When it ships with perl, it will be a reasonable option

It's planned to ship with 5.10 - whenever that may be ;-)

Just as an information point there were over 150 distinct distributions that used Module::Build on CPAN back in October 2003. Probably more now. So there's obviously a section of the Perl world who think it's a reasonable option now. YMMV.

All the reports I've read from authors who have switched (e.g. Mark Stosberg) say that few, if any, complaints were received.

it still irks me that it can't take the same flags (e.g. PREFIX) which we have been trying to teach to newbies without root for eons now

Yeah that is a bit of a pain. It's a swings/roundabouts situation. M::B has a much more sensible structure for installation prefixes than the baroque logic that EU::MM uses. So what's better: use PREFIX and annoy people who expect an exact match for the old behaviour, or change the name and annoy people who have to go read the docs to find out the new mechanism.

My opinion changes depending on the day of the week.

Passthrough Makefile.PLs and auto-installation have worked well in solving the installation issue for me.

That's a pretty poor solution if you weren't already installing via CPAN.pm.

I recently had a case where I was trying to create an automatic build for the Krang CMS that would rebuild a set of modules from source and install them in a local directory without running tests. I made a script using Expect that managed to automatically handle most of the installation. Then I hit Devel::StackTrace, which uses Module::Build. I had to basically write a whole new install procedure for it, since it needed entirely different commands with different options. I also had to install Module::Build first, and all for one module that doesn't even do anything that the simplest Makefile.PL couldn't handle.

I would be more understanding about it if it were being used for things that ExtUtils::MakeMaker can't do. When that isn't the case, it just seems gratuitous.

It claims that "Perl is said to be a language for system administration. Could it really be the case that Perl isn't up to the task of building and installing software?" This absolutely grates -- Perl is about text manipulation and system administration, but it's also about gluing existing parts together. If there's a tried-and-true wheel out there, Perl can usually take advantage of it, rather than having to reinvent it. Even if M::B is made to work as well as make at the moment, it will lead to a constant duplication of effort as platforms change, so long as other projects continue to use make, and therefore keep it up-to-date. As it says in the M::B docs, "It is risky to make major changes to MakeMaker, since it does so many things, is so important, and generally works." So on the one hand, there is crufty code; on the other hand, I appreciate its "generally working." (This sounds like a Perl 5/6 comparison in some ways, and I see neither an effort to convert people to Perl 6 by subtle default, nor a cry that they adopt it simply "because it's new".)

For people who need to do elaborate tweaks to the build process, M::B sounds like a definite improvement. But for the rest of us, and certainly for most users of Module::Simple, EU::MM will minimize pain to both author and users.

Module::Build (0.23, Mac OS 10.2.8, Perl 5.8.3) has been a plague to me by failing to work with CPAN installs

Try 0.24 - I think you may have hit M::B at a bad time. Both 0.22 and 0.23 had some rather annoying bugs with passthrough Makefile.PLs that caused problems when used with CPAN. I suspect that 0.24 will work fine, as would using CPANPLUS which calls Module::Build directly rather than using the Makefile.PL.

I've been using M::B on Mac OS X, various Linux varieties, Free BSD and Solaris with no problems.

Perl is about text manipulation and system administration, but it's also about gluing existing parts together. If there's a tried-and-true wheel out there, Perl can usually take advantage of it, rather than having to reinvent it

The problem is that there isn't a wheel, there are several. The various make variants all work in slightly different ways. Dealing with this is one of the reasons E:MM is so complex. Dealing with this variety when writing extensions is a pain. Then there are those platforms that don't have that particular wheel by default.

Next there is the problem that the declarative makefile style isn't always suitable to express the dependencies and processes you want to happen during a build process. So you have to jump backwards and forwards between the makefile and perl code - which is hard.

Finally there's the problem that EU::MM isn't really built to be extended, so it's a royal PITA for folk like me who need to make custom build processes :-)

For people who need to do elaborate tweaks to the build process, M::B sounds like a definite improvement. But for the rest of us, and certainly for most users of Module::Simple, EU::MM will minimize pain to both author and users.

Depends on the author/user I guess ;-) For those platforms that don't come with a make M::B can be a lot simpler. As a CPANPLUS user I have had zero problems using Module::Build. As a module author I vastly prefer it to EU::MM since it's really easy to extend.

As a CPANPLUS user I have had zero problems using Module::Build.

You see, CPANPLUS falls into the same category as M::B for me, namely "solutions looking for a problem". Both replace modules with supposedly hairy internals that have been carefully tweaked and polished over years to do their jobs quite well. Both have chosen to compete head-on with mature solutions, and both often compete based on criteria (extensibility, maintainability) that are only relevant to a tiny fraction of their users. I wish them well, but you'll have to forgive my not seeing a compelling reason to switch.

As a module author I vastly prefer it to EU::MM since it's really easy to extend.

As a fellow member of the module-authoring elite, I've never needed to extend EU::MM. I'm not sure whose experience is more representative here.

Next there is the problem that the declarative makefile style isn't always suitable to express the dependencies and processes you want to happen

I take this as a challenge... people manage to write major programs in Prolog and Haskell, despite their declarative natures ;). YMMV, of course.

Module::Build patches are welcome.

My - that was quick :-)

From the 0.04 Changes:

  * Added support for Module::Build.  Thanks, Randy Sims.
[download]

Isn't open source great!