Re: [Module::Build] M::B actions design

[Randy W. S. <Ra...@Th...>]

I don't think this made it to the list, so I've forwarded it for Steve.

On Saturday, October 18, 2003, at 10:09  am, Randy W. Sims wrote:

 > On 10/17/2003 11:38 AM, Steve Purkis wrote:
 >
 >> On Friday, October 17, 2003, at 03:57  am, Randy W. Sims wrote:
 >>
 >>> On 10/16/2003 6:50 AM, Steve Purkis wrote:
 >>>
 >>>> On Thursday, October 16, 2003, at 12:06  am, Randy W. Sims wrote:
 >>>>
 >>>>>  M::B would search for plugin actions at startup, querying each 
module for a list of supported actions.
 >>>>
 >>>>
 >>>> So M::B builds up a list of actions and their classes?  And I 
assume it would search particular sub-classes, starting with 
Module::Build::Action?  Maybe that's how you could do user level 
sub-classing: push on your own 'search' package:
 >>>>     @M::B::SearchPackages = qw( My::Action Module::Build::Action );
 >>>
 >>>
 >>> This is where I still have uncertainties. One way that seems kind 
of hackish to me is to scan for '*.pm' under M::B::Action. Then try to 
execute a register function for each module found. If an author provides 
an action that is intended to subclass/override another action, then the 
register function for that action would have to report that in some way. 
I think this kind of usage would be rare in practice. ???
 >>
 >> I've done some work along these lines in the past - right off the 
bat I'll tell ya that looking for *.pm doesn't work as well as you might 
like :-/.
 >> Here are a couple of algorithms I've used in the past (I'm sure 
there's more ;)...
 >> 1. A type map & a register method.
 >> 2. Search packages.
 >
 >
 > My ASSumptions here are that M::B would need to construct a list of 
actions at startup in order to workout overrides by other action authors 
(as opposed to module authors writing Build.PL scripts). I don't think 
either of these designs allow for that, but OTOH that restriction could 
come from a valid design decision.


They both do allow for overrides by other action authors - in (1) you'd 
call the register() method, in (2) you'd modify the list of search packages.

I've just noticed Module-Pluggable going up to CPAN -- haven't had time 
to look at it, but might be worth going over it before making any decisions.


 >>>>> my $top = new M::B::ACTION::Builtin( name => 'all' );
 >>>>> $top->add_dependency($action);
 >>>>
 >>>>
 >>>> I'd go with 'M::B::Action::All', it's more consistent.
 >>>
 >>>
 >>>
 >>> Actually, right now I'm thinking more along the lines of
 >>>
 >>> my $top = new M::B::Action::find_action( name => 'all' );
 >>> $top->add_dependency($action);
 >>>
 >>> to get a reference to an existing action as it seems more flexible.
 >>
 >> Mmm..  so you'd like to be able to compile a list of dependencies 
external to the Actions themselves, eh?  Well, it's not what I was 
thinking but it could work.
 >
 > >
 > > Still, after a bit of thought I'd say keep it simple and sub-class if
 > > ever you want to change the dependency tree.  Which is not as flexible
 > > when you're writing Build.PL's, but it does mean less work for the
 > > person implementing/maintaining M::B's action dispatching code.
 >
 > M::B itself would manage all dependencies. Build.PL authors, action 
authors would be responsible for registering the dependencies with M::B. 
  M::B would also maintain a dispatch table for all actions and be 
responsible for finding and invoking the correct action. So, (third 
times a charm) the above would actually be M::B::find_action(). That 
gives M::B the flexibiliy to chose the correct action when there may be 
overrides involved.


Ahh, ok, that's a different idea than the one I had in mind (let the 
Actions handle the dependencies).  It's really a design decision that's 
gotta be made by Ken I guess.


 > This is about as far as I can think through the design without 
resorting to drawing up some diagrams and taking a close look at the 
existing code, and Ken may already have something better in mind.


Yeah, I think we've put forward some good ideas.  It's up to Ken to 
decide which way forward now.

Cheers,
-Steve