# from Ken Williams # on Tuesday 12 June 2007 09:00 pm: >It's currently exactly analogous to the >other prereq types, except that during the "dist" action we'll warn >the author if there's an item in config_requires that isn't present >in any of the other prereq fields. Earlier today I managed to >convince myself that might be the right way to do things; I can try >to lay out my reasoning here if anyone's interested.
In most cases, M::B will be the only c_r entry (and will be auto.) I would really like to not need to state any explicit M::B requirement in Build.PL, so then you get into special-casing that automagic entry. Plus we're only warning the author about it and not covering the manual-Build.PL scenario. I think we want to treat missing c_r entries as show-stoppers. That is, configure_requires => {Module::Build => 0.28} should be analogous to: use Module::Build 0.28; We're expecting that CPAN(PLUS) will have already addressed the c_r assertions or, in the case of a manual-Build.PL operator, they will go take care of it. Thus, I think die()ing at Build.PL-time is the thing to do. This means a different behavior for c_r entries vs any other *_requires entries (which only warn at Build.PL-time.) Yes, (Adam) there is an "older CPAN(PLUS)" issue there when you die in the middle of a big install, but we need to address that elsewhere (e.g. M::I requires M::B or etc.) If we don't die() when c_r is unsatisfied, we're risking stranger and less diagnosable failures elsewhere. >I haven't figured out the right thing to do vis-a-vis automatically >adding M::B to config_requires. We could select some minimum version of Module::Build and bump that as needed (e.g. "latest official release".) As far as using the value of Module::Build->VERSION, I'm particularly concerned about what happens when I'm running a development version of M::B -- I don't want to be releasing a module that configure_requires a M::B which isn't out yet. This of course depends on the version-bump policy employed in M::B's svn (which afaict seems to be bumped at-release rather than immediately-after-release.) But in general, we should always use $current. A distro can explicitly specify an earlier version if they really need to. --Eric -- So malloc calls a timeout and starts rummaging around the free chain, sorting things out, and merging adjacent small free blocks into larger blocks. This takes 3 1/2 days. --Joel Spolsky --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------