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

[Steve P. <sp...@qu...>]

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