Corion wrote: To me, the "utter lack of help" stems from the fact that module installation is a solved problem, and Module::Build is a reinvented wheel that hasn't really proven it's better ...

Module installation is most definitely not a solved problem. MakeMaker is a spectacular hack that does a wonderful job of handling the majority of needs that most people have but it is not a full-fledged build system. Schwern talks about how difficult it was to try and get MakeMaker to work on Mac Classic and VMS, but they were trivial to add to Module::Build because it's pure Perl. And while it's not public yet, I can guarantee that the sophisticated build work we're doing for Bricolage 2.0 would be very difficult under MakeMaker. Some build requirements (such a variable dependency lists) are beyond the capabilities of MakeMaker primarily because of how difficult they are to add. And does a new OS pop up? Once Perl is ported, there's a good chance that Module::Build will get ported to it immediately and just work. Can't say that for MakeMaker.

MakeMaker is really hard to extend and modify. One day Schwern needs to sit down and try and remember all of the features that he's rejected in MakeMaker because of this. With Module::Build, you have a robust, full-featured build system that's easy to extend, modify, and fix. PREFIX isn't in it yet because of how difficult that is to extract from MakeMaker. Of course, if anyone disputes this, the proof is in the patch.

Module::Build (and I say this with the guilty admission that I haven't ported my modules yet) is the future of build in Perl. It's not where it could be but that is due, in large part, to the fact that many, many years of arcane hacks and business knowledge are squirreled away in the internals of MakeMaker and that's not always easy to port (or well-documented, either). Of course, the fact that people won't use Module::Build until it's perfect doesn't help, either.

I don't buy the "Module::Build will Just Work" crap. I have seen how it doesn't work on Win32, and mostly because of unixisms used. So if the New OS is unlike Unix, Module::Build will not Just Work.

I don't think that Module::Build needs to be extensible. Period. It should get my modules installed. My modules could be installed by a glorified shell script, and if I was keen about worrying, I could use ExtUtils::Command to replicate the functionality myself instead of relying on EU::MM. But I don't want to do that, and EU::MM already works.

I hear Schwern talking when you say Module::Build is the future of build in Perl. Module::Build may indeed be the future of Perl, but it will never be the future of build in Perl5. Perl6 has the luxury of starting from a clean slate and not having to worry about previous bad decisions. Perl5 has PREFIX=.

All the devs keep complaining that nobody uses Module::Build, and then keep complaining again when shortcomings get reported. They also complain about how bad EU::MM is, and they complain that their work on Module::Build is not recognized. I see a pattern there, and I guess that comes into play when considering on what I spend my time.

The Module::Build cabal thinks itself the herald of the future (and behaves like it). This makes them blind and deaf against their users. Which is bad if you wantneed a large user base. If Module::Build does not provide an easy migration path for both, modules and existing installations, it will not go anywhere. And I have not seen any consideration of the Module::Build cabal for existing Perl installations. And the cabal cannot take the hint from the complainers that don't use Module::Build. Because, usually, after two or three complaints, people keep using what they used before (EU::MM) instead of putting up with the Module::Build cabal.