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.

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

Fair point. However when I'm not installing from CPAN I don't find adding one more module to the usually long-list of prerequisites much hassle either.

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.

But those different commands give the end user more options/improved functionality. I prefer install_base to the scary magic that lives behind EU::MM's PREFIX.

I can understand the annoyance that the commands are different, but I think different commands are necessary to support improved functionality.

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 is doing things EU::MM can't do. For example:

• Automatically generating licence meta-data.
• Working on platforms without a make
• Built in help system
• User can diff the distribution with what's installed

Now I can understand that these are not important issues for your particular application, but they (and others) are for me.

I'm not trying to force everybody to move to M::B. There are things it doesn't handle well yet (XS support is still shaky, nested builds, etc.) That said M::B does more of the things that I want more easily than EU::MM. YMMV.