On Wed, Nov 16, 2011 at 1:38 PM, Reini Urban <rurban@x-ray.at> wrote: > Module::Build is e.g. a prime example, where a native make replacement > never got to the level of a make replacement, though it should have > been possible with ~200 lines to get dependency handling in perl. This > module still forces maintainers to drop 5.6. That's a non-sequitur. M::B followed Schwern in dropping support for Perl's older than 5.6.1. Backcompatibility has maintenance costs, which I opted not to continue paying. No, M::B's design is not recursive dependency resolution like "make". Whether you think it should have been or not is pretty much moot at this point. And it has nothing to do with the version of Perl supported. M::B wasn't in core until 5.10, so any discussion prior to that about Perl 5.X or 5.Y with respect to it is largely irrelevant anyway. It wasn't until 5.10.1 that the core shipped CPAN clients that universally recognized configure_requires in META.yml, which is the first point at which I consider the core toolchain sane for *any* sort of build customization. So, yeah, you can state "5.6 is fast and almost never wrong compared to 5.14" -- as long as your definition of "never wrong" includes a broken toolchain that increasingly couldn't cope with real-world things released to CPAN. Separately, if you think a pure-perl make replacement can be done in ~200 lines portably across platforms, please feel free to write one. The Build.PL spec is now fairly well established and the toolchain easily works with alternatives now (e.g. Module::Build::Tiny). The space is wide open for innovation by "experienced hackers". -- David