Eric Wilhelm wrote:
# from Adam Kennedy
# on Friday 27 October 2006 08:38 pm:
As I've explained a few times now requires and build_requires (and
dev_requires/devel_require etc if we get them) can ONLY reliably be
determined by running the Build.PL to resolve variations in
dependencies on different platforms.
Please give a realistic example of requiring different *build* or
*install* plugins on different platforms. Perhaps my builder.pm hack
needs rethinking.
If by *install*, you mean run-time, there's tons of them on the CPAN, as
one example see File::HomeDir.
As for build, none off the top of my head, but that's not to say they
don't exist.
Actually, as long as Module::Build::Plugins runs on all platforms,
you'll still be able to just build_requires MBP (if you really need an
install plugin) and builder('Module::Build::Pluggable') then returns
'Module::Build::Pluggable' and hopefully your custom build class can
handle the rest at runtime.
What part of that does not work for you?
I think it is okay if dev_requires takes a bit of critical thinking.
Most programmers should be able to understand the concept of a
dependency. Sure, I would love for it to be seamless, but it is not
worth blocking the deployment of a 98% solution.
It also means that plugins won't be allowed if you have different
dependencies on different platforms.
I cannot really see a good reason to dynamically choose a
platform-specific M::B plugin. If the plugin needs something special,
that is solved during its own install process. Thus, which *plugin*
your build requires is static. If that doesn't work for some reason,
just release another plugin and declare a static dependency on it.
The problem is not that you would choose different plugins.
It's that you cannot BOTH use a plugin and also have host-specific
(which includes platform-specific) dependencies.
If you need the plugin installed at perl Build.PL-time, then anything
that would not work under dynamic_config: 0 breaks the plugin.
Adam K
