And not being able to run Build.PL due to missing Module::Build at all is an advantage right now why? There is the Vanilla/Strawberry Perl initiative which caters for the people who don't have Visual C and the corresponding make tool, and so far I think that's the better approach than waiting for 5.10 becoming so widespread that using Module::Build becomes a viable path.
Another very good option is Module::Install, which even tells the user where/how to download and install nmake if it's not found. Which EU:MM could do as well, but ...
| [reply] [d/l] [select] |
How about the fact that extending EU::MM is an exercise in frustration while extening M::B is much easier. Module::Install, while ok, is Adam Kennedy's frustration manifesting itself.
The point here is that Perl shouldn't have to depend on make, period. If you are installing a Perl module, you are guaranteed to have Perl. There is no need to depend on an outside tool that 90% of all computers in the world don't have installed by default.
Now, granted, M::B should probably have gone the pmake route vs. re-rolling that wheel, but that's another complaint.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Uh, sorry - that's a bogus argument. EU:MM works now for every stable Perl (5) version, out of the box. This is something that Module::Build cannot and will never* be able to claim. There is little reason to "extend it" beyond the vanity of the Module::Build authors. Module::Build is a good idea followed by a long sequence of bad decisions and I get tired of people touting Module::Build as the bees knees. Those people are mainly the authors of Module::Build, who refrain from realizing why Module::Build hasn't seen the vast wave of adoption that was proclaimed when the project started. It may be cool for the maintainers of Module::Build and it might offer many benefits for module authors, like specifying what license your module has, or what testing dependencies your module has, but for the majority of people, the module users, Module::Build is just additional hassle, especially if it's not already.
Module::Install is no additional hassle for the module user and even has an auto-upgrade method in case the module author distributed an old/buggy version of Module::Install and you want to use a newer version. It caters to the module user at least as much as the module author, and it circumvents the whole compatibilty and installation crap that Module::Build has (had to) fight.
* "Never" as in "as long as there are operating systems that come with a stock Perl with a version less than 5.10. Which will be for the next five years at least.
| [reply] |
To be honest, I know almost nothing of Microsoft's make-a-like, because I avoid Windows most of the time. I gather EU::MM works with Windows Make's current state. In my UN*X/Mac experience, M::B is a poorly-reinvented EU::MM wheel, but I can't vouch for Vista. | [reply] |