Note that the first link is to a post by M::B's author, and the second basically points to the third, then says "nyah, nyah, I'm only supporting M::B with my modules." Also, as has been stated many times here and elsewhere, these only mention reasons for *authors*, not for *users*. As a user I find M::B a step backwards, and as an author I've never needed its extra features. So if these are the "plenty of good reasons", color me unconvinced. | [reply] |
Did I hear you volunteer to keep the link to whatever Microsoft calls their free make equivalent up to date so that people who want to install CPAN modules on Windows when they already have Perl installed can do it simply and easily?
Let me know if you need more advantages of M::B (or, more properly, shortcomings of EU::MM). I could tell you stories about MY::....
| [reply]
[d/l]
[select] |
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] |
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] |
