On Jul 25, 2006, at 5:33 PM, Julian Mehnle wrote:
Ken Williams wrote:
On Jul 17, 2006, at 4:53 PM, Eric Wilhelm wrote:
If you want to maintain parallel EU::MM and M::B files for
version.pm,
that's up to you. I'm just wondering what happens when any of these
(there may be more -- this is just a quick check against 5.8.8 core)
decide to switch to using M::B?
Module::Signature
ExtUtils::ParseXS
Archive::Tar
Pod::Readme
ExtUtils::CBuilder
YAML
Pod::HTML
I guess the most streamlined solution would be for those modules to
bundle M::B rather than the other way around, because they only
build_require it, whereas we really require them at runtime.
So whenever M::B decides to create a _new_ dependency, that
dependency will
have to bundle M::B? That doesn't sound right.
No, I didn't mean they should have to. I meant it would be the
easiest and most lightweight way to break the dependency circle from
the user's point of view, because nothing extra would need to get
installed on the user's machine. But that decision can and should be
left up to whomever the maintainer is.
And yet another angle: If YAML (for instance) has to bundle M::B,
it then
will have to bundle Module::Signature, ExtUtils::ParseXS,
Archive::Tar,
etc., too, or the bundled M::B won't be able to run in order to
install
YAML and you won't have solved anything.
That's not true, none of those dependencies would be needed. Those
are all optional dependencies, some of which are just used by module
authors and not module installers (Module::Signature, Archive::Tar,
etc.) and some are not needed for YAML because it doesn't have any XS
code (EU::ParseXS, EU::CBuilder).
Recursive build dependencies is a broken concept by design.
What's a recursive build dependency?
-Ken
