# from David Golden
# on Thursday 26 November 2009 05:10:
>How about this:
>
>(1) We add a "testrelease" action that sets RELEASE_TESTING and calls
>a list of other testing actions
>
>(2) We add a 'testxt' action that runs tests in xt/; this is common
>enough now that we might as well make it easy
>
>(3) We add a 'release_test_actions' parameter to set the list. This
>would default to qw/test testxt testpod distcheck disttest/ but could
>be overridden in arguments to new()
>
>...Build release' would be easy to do...
This has triggered my semi-biyearly ponderance of plugins. I
think "tools for authors" should be doable outside of M::B. And/or
more easily customized than via subclassing, plus more easily shared
between distributions than via copy+paste.
What is mentioned above covers most of what CPDK::Publish does, but I
guess having it inside the build system would work just as well. In
any case, I want to be able to drive it via layered config files so
that machine+user+project settings are manageable.
For general thoughts about plugins: We've discussed before/after hooks
and I think that's the way to go (maybe just a hash of arrays of
subrefs -- maybe run by _call_action() or even something installed in
the ACTION_foo slot.) The missing piece (as I see it) is something to
load the plugins and perhaps be lazy enough that dev tools don't have
to be available for `./Build install` to work.
That is, if an action like 'release' is defined by a missing plugin,
`./Build release` should fail with a nice message about which plugin to
install (or even a prompt "should I get this from the CPAN and install
it now?".) For that to work, the Build.PL just needs to somehow
declare that a method would be provided by $plugin.
plugins => [release => 'Module::Build::Plugins::Release']
Given a suitable config directive, I guess one could even automatically
declare a plugin as being build_requires or configure_requires (we
could deduce that from a short list of actions.) Perhaps e.g.
plugins => [
before_configure => 'Module::Build::Plugins::CheckLib' => [
requires_lib => 'usb',
],
before_build => 'Module::Build::Plugins::Inline',
before_build => 'Module::Build::Plugins::Podify',
]
Note that we can't use a more typical "plugin configures itself"
approach (e.g. call the plugin's init() method after loading) because
M::B needs to run on installation targets where a dev plugin might not
be available and in other cases we need to have enough info to
automatically declare dependencies or perhaps even handle bundling.
But the plugins probably need to still declare something about what
they provide so the loader can double-check against what is in
Build.PL.
--Eric
--
"Matter will be damaged in direct proportion to its value."
--Murphy's Constant
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
