# from David Golden
# on Tuesday 23 February 2010 17:17:
>> The easy thing would be to remove the Build.PL from
>> ExtUtils::ParseXS, ExtUtils::CBuilder, etc (but only because we have
>> comaint on those.)
>
>We know who the maintainers are and can encourage them. Test::Harness
>is already done. EU::Install probably should be changed, too.
I can't argue with results, but the irony! If Module::Build decides to
depend on you, you have to switch to ExtUtils::MakeMaker?
>> Slightly more difficult would be to remove them from our 'requires'
>> (since they are not strictly required) and insert them in
>> build_requires as needed (in META.yml and MYMETA.yml). I think this
>> would actually be more correct. David, what was the logic for these
>> recent additions to 'requires'?
>
>The logic was that installation of M::B should ensure a "sane"
>toolchain, where "sane" is defined by me to mean "recent enough to
>have substantial numbers of bugs fixed".
I don't like this mission-creep. That should be Task::Toolchain or
something.
It looks like ExtUtils::ParseXS, ExtUtils::CBuilder, Test::Harness, and
possibly File::Spec are the only modules which aren't in old core.
The first two are not needed until we try to actually build something.
Test::Harness should maybe be bundled in M::B if we need it there to
test ourselves. As far as what's required to test an actual dist, that
should just be a test_requires emitted during *that* dist's Build.PL.
--Eric
--
Chicken farmer's observation: Clunk is the past tense of cluck.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
