module-build-general — General discussion about Module::Build project

Re: [Module::Build] Module::Build Report

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

On 10/22/2003 9:39 PM, Ken Williams wrote:

 >
 > On Wednesday, October 22, 2003, at 08:33  PM, Randy W. Sims wrote:
 >
 >>
 >>
 >> I was curious to see what modules where using M::B, and I also thought
 >> having a list of those module might be useful. I used Randal
 >> Schwartz's minicpan script to update my local archive with just the
 >> most recent versions of each module from CPAN. I then wrote a little
 >> script to peek inside each of those modules and generate the attached
 >> report.
 >>
 >> The first field in the report (which is empty in this edition) would
 >> have an XS if any XS modules where present. The second field is the
 >> CPAN author ID for the module author, and the third field is the
 >> module name-version.
 >
 >
 > Interesting.  I guess I'd better add a Build.PL to AI-DecisionTree,
 > because it has some XS parts to it.
 >
 > Actually, I think some of the dists do have XS parts.  B-Generate, for
 > example.
 >
 >  -Ken
 >
 >

You're right. I was searching for $file_names =~ /\.XS$/ exactly when I 
should have been using a case insensitive search. So the following are 
modules with a 'Build.PL' script that do contain XS code.

XS ABERGMAN   B-Generate-1.06
XS LBROCARD   Image-Imlib2-1.00
XS MOLT       SDL-OpenGL-Cg-0.01
XS RCLAMP     Devel-Caller-0.09
XS RCLAMP     Devel-LeakTrace-0.05
XS RCLAMP     Pod-Coverage-0.12

Randy.

[Module::Build] Module::Build Report

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

I was curious to see what modules where using M::B, and I also thought 
having a list of those module might be useful. I used Randal Schwartz's 
minicpan script to update my local archive with just the most recent 
versions of each module from CPAN. I then wrote a little script to peek 
inside each of those modules and generate the attached report.

The first field in the report (which is empty in this edition) would 
have an XS if any XS modules where present. The second field is the CPAN 
author ID for the module author, and the third field is the module 
name-version.

Randy.

Re: [Module::Build] ANNOUNCE: 0.21 released

[Ken W. <ke...@ma...>]

On Monday, October 20, 2003, at 04:34  AM, Randy W. Sims wrote:

> Andrew Savige wrote:
>> The next release of Archive::Tar (1.08) will fix the bug of adding
>> directories to tarballs failing under Windows (so the above grep
>> workaround should then become unnecessary). If you need a patch
>> for this bug now, please let me know.
>
> Hi Andrew, Thanks for the quick fix; It's good to know that 
> Archive::Tar is now being actively maintained.
>
> Ken, Since a file stat and test is a relatively expensive operation, 
> and since the chatter produced is non-fatal, doesn't break anything, 
> and will go away in future versions of Archive::Tar, I would suggest 
> reverting this change. If anyone complains about the chatter, we can 
> suggest that they bump their version of Archive::Tar.

Agreed - done.

  -Ken

Re: [Module::Build] [patch] cccdlflags

[Ken W. <ke...@ma...>]

Thanks, applied.

  -Ken

On Monday, October 20, 2003, at 07:29  AM, Richard Clamp wrote:

> I have a ticket against Pod::Coverage[0] which I think to be a
> Module::Build issue, namely when invoking the C compiler the -fpic
> from $Config{cccdlflags} isn't propagated to the cc command line as
> MakeMaker does.
>
> Attached is a minimal patch for this - it doesn't disturb any of the
> existing XS tests, but I have a feeling it's correct by examining
> ExtUtils::MM_Unix
>
> [0] http://rt.cpan.org/NoAuth/Bug.html?id=4157
>
> -- 
> Richard Clamp <ric...@un...>
> <cccdlflags.patch>

Re: [Module::Build] [patch] cccdlflags

[Mathieu A. <ma...@Fr...>]

+-Le 20/10/2003 16:07 +0100, Richard Clamp =E9crivait :
| On Mon, Oct 20, 2003 at 04:48:29PM +0200, Mathieu Arnold wrote:
|> Hey, that's my ticket :)
|> If someone here needs some testings on a amd64 box, I'll be glad to run
|> them for you.
|=20
| I'd expect that running of the t/xs.t should have already exposed the
| issue on your build box, but I don't see an errorlog for
| Module::Build.  Are successful build logs discarded, or would I have
| to look somewhere else for those?

I'd say that it's there :
<http://bento.freebsd.org/errorlogs/amd64-5-latest-logs/p5-Module-Build-0.2
1.log>
And build don't make test.
I'll try to run make test on this box.

--=20
Mathieu Arnold

Re: [Module::Build] [patch] cccdlflags

[Mathieu A. <ma...@Fr...>]

+-Le 20/10/2003 13:29 +0100, Richard Clamp =E9crivait :
| I have a ticket against Pod::Coverage[0] which I think to be a
| Module::Build issue, namely when invoking the C compiler the -fpic
| from $Config{cccdlflags} isn't propagated to the cc command line as
| MakeMaker does.
|=20
| Attached is a minimal patch for this - it doesn't disturb any of the
| existing XS tests, but I have a feeling it's correct by examining
| ExtUtils::MM_Unix

Hey, that's my ticket :)
If someone here needs some testings on a amd64 box, I'll be glad to run
them for you.

--=20
Mathieu Arnold

Re: [Module::Build] [patch] cccdlflags

[Richard C. <ric...@un...>]

On Mon, Oct 20, 2003 at 04:48:29PM +0200, Mathieu Arnold wrote:
> Hey, that's my ticket :)
> If someone here needs some testings on a amd64 box, I'll be glad to run
> them for you.

I'd expect that running of the t/xs.t should have already exposed the
issue on your build box, but I don't see an errorlog for
Module::Build.  Are successful build logs discarded, or would I have
to look somewhere else for those?

-- 
Richard Clamp <ric...@un...>

[Module::Build] [patch] cccdlflags

[Richard C. <ric...@un...>]

I have a ticket against Pod::Coverage[0] which I think to be a
Module::Build issue, namely when invoking the C compiler the -fpic
from $Config{cccdlflags} isn't propagated to the cc command line as
MakeMaker does.

Attached is a minimal patch for this - it doesn't disturb any of the
existing XS tests, but I have a feeling it's correct by examining
ExtUtils::MM_Unix

[0] http://rt.cpan.org/NoAuth/Bug.html?id=4157

-- 
Richard Clamp <ric...@un...>

Re: [Module::Build] ANNOUNCE: 0.21 released

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

Andrew Savige wrote:
> The next release of Archive::Tar (1.08) will fix the bug of adding
> directories to tarballs failing under Windows (so the above grep
> workaround should then become unnecessary). If you need a patch
> for this bug now, please let me know.
> 

Hi Andrew, Thanks for the quick fix; It's good to know that Archive::Tar 
is now being actively maintained.

Ken, Since a file stat and test is a relatively expensive operation, and 
since the chatter produced is non-fatal, doesn't break anything, and 
will go away in future versions of Archive::Tar, I would suggest 
reverting this change. If anyone complains about the chatter, we can 
suggest that they bump their version of Archive::Tar.

Randy.

Re: [Module::Build] ANNOUNCE: 0.21 released

[<ajs...@ya...>]

Randy W. Sims wrote:
> Ken, Since a file stat and test is a relatively expensive operation, and 
> since the chatter produced is non-fatal, doesn't break anything, and 
> will go away in future versions of Archive::Tar, I would suggest 
> reverting this change. If anyone complains about the chatter, we can 
> suggest that they bump their version of Archive::Tar.

Just to clarify, though I'm the hoplite for Archive:Tar (see
http://qa.perl.org/phalanx/ if you don't know what a "hoplite" is ;-)
I can't guarantee when the next release (1.08) of Archive::Tar will be
made (that is up to Jos). However, I'm confident this will be fixed in
the next release because I sent the File.pm patch to Jos yesterday and
he has already put it in his p4 repository.

Now that everyone knows what a hoplite is, I'm sure Ken will be flooded
with volunteers for the very prestigious title of, dada:

         *** Module::Build hoplite ***

;-)

/-\


http://personals.yahoo.com.au - Yahoo! Personals
New people, new possibilities. FREE for a limited time.

Re: [Module::Build] ANNOUNCE: 0.21 released

[<ajs...@ya...>]

"Randy W. Sims" wrote:
> There is also something going on at t/runthrough.t #20. I think I 
> upgraded the Tar module recently, that may have something to do with 
> it as it has always been troublesome on Windows.

Avoid Archive-Tar-1.06 (which only lasted 2 days).
v 1.07 fixed an important Windows bug; the next version will fix more.

/-\ (who has just started helping Jos with Archive::Tar Windows testing)


http://personals.yahoo.com.au - Yahoo! Personals
New people, new possibilities. FREE for a limited time.

Re: [Module::Build] ANNOUNCE: 0.21 released

[<ajs...@ya...>]

"Randy W. Sims" wrote:
> On 10/15/2003 11:22 PM, Randy W. Sims wrote:
> > There is also something going on at t/runthrough.t #20. I think I 
> > upgraded the Tar module recently, that may have something to do with it 
> > as it has always been troublesome on Windows.
> > 
> > Randy.
> 
> This chatter comes from tring to add directories to the tarball. 
> grepping before passing the list to create_archive() fixes this problem.
> 
> sub make_tarball {
>    my ($self, $dir) = @_;
> 
>    require Archive::Tar;
>    my $files = $self->rscan_dir($dir);
> 
>    print "Creating $dir.tar.gz\n";
>    Archive::Tar->create_archive("$dir.tar.gz", 1, grep !-d, @$files);
> }

The next release of Archive::Tar (1.08) will fix the bug of adding
directories to tarballs failing under Windows (so the above grep
workaround should then become unnecessary). If you need a patch
for this bug now, please let me know.

/-\


http://personals.yahoo.com.au - Yahoo! Personals
New people, new possibilities. FREE for a limited time.

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

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

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

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

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:
>>>
>>>> <thinking out loud>
>>>>
>>>> Each module would contain one or more actions.
>>>
>>> I'd limit it to one a package.  That way you can get the action name 
>>> from the package name itself:
>>>     'build' => M::B::Action::Build
>>
>>
>> It would be more convenient to allow multiple related actions to share 
>> a file so that they can share common functions/data. Also, it's best 
>> if they do not share the name because the most appropriate name for an 
>> action might be a perl keyword. The module should have a descriptive 
>> name appropriate for the actions it contains. The actions 
>> (packages/classes) themselves should probably follow the current 
>> standard of prefacing them with 'ACTION_' to avoid conflicts.
> 
> 
> I see where you're coming from, but I still disagree.  Here's why:
> 
> 1. Simplicity.
> This is the key, really.  A class that does one thing and does it well 
> is easier to write, maintain, understand and sub-class.  There's also 
> less to go wrong, and it will make dispatching the actions a lot easier, 
> seeing as each action would be dispatched in the same way:
> 
>     $action->dispatch();    # thank you Pipeline.pm :)
> 
> 2. Common code can be inherited or called out.
> We talked about inheritance above; with dependencies between actions, 
> common code can be easily called out.  The M::B API for actions would 
> also fit in here.
> 
> 3. Highly configurable.
> If each action is implemented as a small unit of code, you could easily 
> change the behaviour of the system by replacing one of the units.
> 
> I don't think having an action that has the same name as a perl keyword 
> (say 'if') would be a problem here.
> 
> 

Ok, I'm willing to conceed. I think my main objection was aesthetic; it 
would mean a lot of subclasses (nearly two dozen for builtins).

>>>>  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.
> The idea is you have an hash like the 'ActionClassMap' I mentioned 
> before (pls forgive the studley caps :).  That hash is populated 
> internally by the module author:
> 
>     package Module::Build::Action;
>     our %ActionClassMap =
>       (
>        Build => 'My::Action::Build',
>        ...
>       );
> 
> Externally, that hash is populated by a 'register' method like the one 
> you had above:
> 
>     package My::Module::Action::Build;
>     use base qw( Modle::Build::Action::Build );
>     Module::Build::Action->register( build => __PACKAGE__ );
>     # or alternatively:
>     __PACKAGE__->register( 'build' );
> 
> 2. Search packages.
> This option is potentially less work, but not as flexible in naming 
> convention - the idea is you have a rule for naming action classes under 
> a namespace, and an ordered list of packages to search.  For example:
> 
>     # assuming a 'ucfirst' rule:
>     $class       = ucfirst( $action ); # 'build' => 'Build'
>     @search_pkgs = qw( Module::Build::Action );
> 
>     foreach my $pkg ( @search_pkgs ) {
>         $pkg .= "::$class";
>         return $pkg if $pkg->can( 'new' );
>         eval "require $pkg";
>         return $pkg unless $@;
>     }
> 
>     die "couldn't find action $action\n";
> 
> 
> 

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.

>>>> 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.
 >
 > -Steve

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.


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.

A couple a good design exercises might be 1) to write a sample Build.PL 
script and a plugin that uses the as-yet-unimplimented interface, and 2) 
draw a call graph that follows execution from the time the user invokes 
'./Build action' and decide what methods get called, what class they 
belong to, and what they do. (Standard stuff)

In any case, I would suggest that a good first phase might be to look at 
all of the existing ACTION_* subs and modify them so that they don't 
access M::B's innards directly and simultaneously build up an API.

Then it might be possible to play around with different plugin designs. 
I think the key to this phase will be two routines. 1) something along 
the lines of M::B::scan_plugins() that would magically locate plugins, 
passing each to... 2) a M::B::register_plugins() routine that would 
build the master dispatch table (resolving any overrides) and depenency 
trees. It would also be responsible for creating virtual stub functions 
in M::B::Base that simply forward the calls to the appropriate plugin. 
These stubs will allow back-patability, and I think they will allow a 
solution to Ken's two design conflicts mentioned in another message.

Regards,
Randy.

Re: [Module::Build] make test failure report (Cygwin)

[Ken W. <ke...@ma...>]

Applied, thanks.

  -Ken

On Wednesday, October 15, 2003, at 11:44  PM, Randy W. Sims wrote:
> patch attached.
>
> Randy.
> diff -ur Module-Build-0.21-orig/t/common.pl 
> Module-Build-0.21/t/common.pl
> --- Module-Build-0.21-orig/t/common.pl	2003-10-16 00:38:57.000000000 
> -0400
> +++ Module-Build-0.21/t/common.pl	2003-10-16 00:29:57.000000000 -0400
> @@ -36,4 +36,21 @@
>    return <$fh>;
>  }
>
> +sub find_in_path {
> +  my $thing = shift;
> +
> +  require Config;
> +  my @path = split $Config{path_sep}, $ENV{PATH};
> +  my @exe_ext = $^O eq 'MSWin32' ? ('', # may have extension already
> +    split($Config{path_sep}, $ENV{PATHEXT} || '.com;.exe;.bat')) :
> +    ('');
> +  foreach (@path) {
> +    my $fullpath = File::Spec->catfile($_, $thing);
> +    foreach my $ext ( @exe_ext ) {
> +      return "$fullpath$ext" if -e "$fullpath$ext";
> +    }
> +  }
> +  return;
> +}
> +
>  1;
> diff -ur Module-Build-0.21-orig/t/compat.t Module-Build-0.21/t/compat.t
> --- Module-Build-0.21-orig/t/compat.t	2003-10-16 00:38:57.000000000 
> -0400
> +++ Module-Build-0.21/t/compat.t	2003-10-16 00:32:33.000000000 -0400
> @@ -6,7 +6,8 @@
>  use Config;
>  require File::Spec->catfile('t', 'common.pl');
>
> -skip_test("Don't know how to invoke 'make'") unless $Config{make};
> +skip_test("Don't know how to invoke 'make'")
> +  unless $Config{make} and find_in_path($Config{make});
>  plan tests => 2 + 3*13;
>  ok(1);  # Loaded
>

Re: [Module::Build] ANNOUNCE: 0.21 released

[Ken W. <ke...@ma...>]

On Thursday, October 16, 2003, at 10:29  PM, Randy W. Sims wrote:

>
>
> On 10/15/2003 11:22 PM, Randy W. Sims wrote:
>> There is also something going on at t/runthrough.t #20. I think I 
>> upgraded the Tar module recently, that may have something to do with 
>> it as it has always been troublesome on Windows.
>> Randy.
>
> This chatter comes from tring to add directories to the tarball. 
> grepping before passing the list to create_archive() fixes this 
> problem.
>
> sub make_tarball {
>   my ($self, $dir) = @_;
>
>   require Archive::Tar;
>   my $files = $self->rscan_dir($dir);
>
>   print "Creating $dir.tar.gz\n";
>   Archive::Tar->create_archive("$dir.tar.gz", 1, grep !-d, @$files);
> }
>

Looks good, applied.  Thanks.

  -Ken

Re: [Module::Build] ANNOUNCE: 0.21 released

[Ken W. <ke...@ma...>]

On Wednesday, October 15, 2003, at 10:25  PM, Randy W. Sims wrote:

> ok 16
> Deleting  
> T:\MIRROR\www.cpan.org\modules\by-module\Module\Module-Build-> 0.21\t\ins
> tall_test
> Deleting blib
> Deleting lib/Sample/Script
> Deleting _build
> Deleting Build
> ok 17
> ok 18
> not ok 19
> # Test 19 got: <UNDEF> (t\install.t at line 102)
> #    Expected: 'lib\Sample\Docs.pod'
> #  t\install.t line 102 is:   ok $pods->{$expect}, $expect;
>


It looks like File::Find isn't localizing the path to use backslashes  
on your system.  Is this an older File::Find?

Maybe I should explicitly the results of rscan_dir() using  
localize_file_path() inside _find_file_by_type().

  -Ken

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

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

On Friday, October 17, 2003, at 03:57  am, Randy W. Sims wrote:
>
> Thanks for the discussion; It has caused me think this through a=20
> little more thoroughly.

Likewise - I'm glad I'm not the only one thinking about this, and it's=20=

good to talk it over.


>  But the thoughts below should still be considered idealizations and=20=

> may differ from the possible or practical. ;)
>
> On 10/16/2003 6:50 AM, Steve Purkis wrote:
>> On Thursday, October 16, 2003, at 12:06  am, Randy W. Sims wrote:
>>> There is another issue here in that the list of actions is growing=20=

>>> quite large, and M::B is (IMHO) turning into a large monolithic=20
>>> module. Would it be worth the effort to re-architect actions, so=20
>>> that they are plug-ins (M::B::ACTION::html, M::B::ACTION::dist).=20
>>> This would keep M::B from becoming monolithic and would allow others=20=

>>> to develop plug-ins to expand functionality without requiring=20
>>> invasive code changes.
>> Yes, M::B: is becoming quite monolithic.  So was MakeMaker.  The main=20=

>> difference I find between the two is that M::B is much easier to=20
>> read, understand and extend.
>
> I didn't realize until now that my original choice of words may have=20=

> been misconstrued as an insulting remark--That was not my intent. I=20
> meant monolithic in the sense that most of the code is in a single=20
> file/class (M::B::Base) that it is growing quite large, and it is not=20=

> likely to get smaller. I didn't intend it as an insult or as any kind=20=

> of judgemental statement, just as an observation.

I don't think anyone interpreted it in an insulting way :).  Also, the=20=

above was more a blaz=E9 remark than anything else.


>> Splitting out the actions is not a bad idea - I bounced a similar one=20=

>> around with some friends in the past:
>>     package My::Action;
>>     use base qw( Module::Build::Action );
>>     use constant depends_on =3D> qw( foo, bar );
>>     sub builder { }    # the parent M::B obj
>>     sub check_dependencies {
>>         ...
>>     }
>>     sub execute {
>>         ...
>>     }
>> There are a few problems with these ideas: how do you write platform=20=

>> specific code?  One answer is to sub-class each action, or write a=20
>> method for each platform in the action's class.  That could work, but=20=

>> it could also get a bit hairy.
>
> The idea(l) is that M::B provide as much as possible an API for the=20
> action plugins that is platform independent. If there are still OS=20
> differences and they are small, they can be put inline. Otherwise, you=20=

> would create subclasses that handled the differences and use the=20
> 'base' class as a proxy, forwarding the calls to the appropriate=20
> 'subclass'.
>
> i.e. if you write an action, say for reporting build status to=20
> cpan-testers called M::B::Action::Reports. If there are differnces=20
> between *nix systems & Windows, you'd create classes=20
> M::B::Action::Reports::Unix & M::B::Action::Reports::Windows. Now, in=20=

> M::B::Action::Reports you'd write stub functions that determinse the=20=

> appropriate subclass to call based on OS and forward the call to the=20=

> real function in the determined subclass.

Yeah, that would do the trick.


>> Then, how do you access commonly used methods?  A solution might be=20=

>> to bung all these methods in a common place that everybody inherits=20=

>> from, say M::B::Common:
>>     M::B::Common
>>         |
>>         +- M::B::Base
>>         |
>>         +- M::B::Action
>>               |
>>               +- M::B::Action::Foo
>
> Again, the common methods would become part of M::B's API for actions.=20=

> (Nit: It's a bad idea to subclass just to share code.)

I disagree - sharing code is one of the best reasons to subclass.  But=20=

I don't want to be pedantic here, because I think having a API for M::B=20=

actions is an excellent idea, and I imagine it would be a bit of mix &=20=

match as to what makes more sense in the sub-class, and what makes more=20=

sense in the API.


>> And, how do you subclass actions?  If I want to write my own=20
>> 'install' action, how do I do it?  At the moment, I sub-class M::B=20
>> and do it there.  Sub-classing each action is easy, but how do you=20
>> get M::B to use them?  One way is to say M::B::Base must have stub=20
>> methods for each action so that they can be overridden.
>
> As an Build.PL author, you would do one of two things.
>
> 1) You'd use a helper class, something like
>
> my $action =3D new M::B::Action::Builder(
>   name =3D> 'install',
>   code =3D> sub {...},
>   help =3D> 'A help message to display for users.'
> );
>
> M::B::Action::register( $action );

Cool idea - fits in well with Module::Build->subclass().  The=20
registration could be done automatically by the builder too.

As an aside, I'd move the Builder somewhere else and reserve the=20
M::B::Action:: namespace for actions only.


> or 2) You'd create an inline class and register it:
>
> package MY::Action::install;
> use Module::Build::Action::Install;
> use vars qw(@ISA);
> @ISA =3D qw(Module::Build::Action::Install);
> sub new { return Module::Build::Action::register( bless \my $arse ) }
> sub ACTION_install { ... }
>
> package main
> new MY::Action::install;
> ...

If you're gonna use a register() method, I'd say do it at a class=20
level, and keep with Perl's naming convention (lowercase reserved for=20
pragmas):

	package My::Action::Install
	use base qw( Module::Build::Action::Install );
	Module::Build::Action->register( install =3D> __PACKAGE__ );

	sub dispatch { ... } # or execute() or whatever()

(This is still assuming you have one action per package - I'll get to=20
that below).


>> I think they all stem from the fact that M::B was not written with=20
>> this design in mind, so it would take a lot of effort to refactor=20
>> things.  It certainly would involve a *lot* of changes, and little=20
>> (if any) backwards compatibility.  There is potentially a huge gain=20=

>> as far as simplicity is concerned, but it may be more work than it's=20=

>> worth.
>
> Yeah, I have no doubt it would be difficult to change, but M::B is not=20=

> going to get smaller. So, any refactoring is best done sooner than=20
> later.

Good point.


>> That said...
>>> This is only half thought-out, so I'm not sure if it's practical.=20
>>> For example, I don't know how easy it would be to come up with an=20
>>> interface so that actions could get info from M::B without digging=20=

>>> into the internals.
>> Making them plugins is a good idea, but it's even more complicated.
>>> <thinking out loud>
>>>
>>> Each module would contain one or more actions.
>> I'd limit it to one a package.  That way you can get the action name=20=

>> from the package name itself:
>>     'build' =3D> M::B::Action::Build
>
> It would be more convenient to allow multiple related actions to share=20=

> a file so that they can share common functions/data. Also, it's best=20=

> if they do not share the name because the most appropriate name for an=20=

> action might be a perl keyword. The module should have a descriptive=20=

> name appropriate for the actions it contains. The actions=20
> (packages/classes) themselves should probably follow the current=20
> standard of prefacing them with 'ACTION_' to avoid conflicts.

I see where you're coming from, but I still disagree.  Here's why:

1. Simplicity.
This is the key, really.  A class that does one thing and does it well=20=

is easier to write, maintain, understand and sub-class.  There's also=20
less to go wrong, and it will make dispatching the actions a lot=20
easier, seeing as each action would be dispatched in the same way:

	$action->dispatch();	# thank you Pipeline.pm :)

2. Common code can be inherited or called out.
We talked about inheritance above; with dependencies between actions,=20
common code can be easily called out.  The M::B API for actions would=20
also fit in here.

3. Highly configurable.
If each action is implemented as a small unit of code, you could easily=20=

change the behaviour of the system by replacing one of the units.

I don't think having an action that has the same name as a perl keyword=20=

(say 'if') would be a problem here.


>>>  M::B would search for plugin actions at startup, querying each=20
>>> module for a list of supported actions.
>> So M::B builds up a list of actions and their classes?  And I assume=20=

>> it would search particular sub-classes, starting with=20
>> Module::Build::Action?  Maybe that's how you could do user level=20
>> sub-classing: push on your own 'search' package:
>>     @M::B::SearchPackages =3D qw( My::Action Module::Build::Action );
>
> This is where I still have uncertainties. One way that seems kind of=20=

> hackish to me is to scan for '*.pm' under M::B::Action. Then try to=20
> execute a register function for each module found. If an author=20
> provides an action that is intended to subclass/override another=20
> action, then the register function for that action would have to=20
> report that in some way. I think this kind of usage would be rare in=20=

> practice. ???

I've done some work along these lines in the past - right off the bat=20
I'll tell ya that looking for *.pm doesn't work as well as you might=20
like :-/.

Here are a couple of algorithms I've used in the past (I'm sure there's=20=

more ;)...

1. A type map & a register method.
The idea is you have an hash like the 'ActionClassMap' I mentioned=20
before (pls forgive the studley caps :).  That hash is populated=20
internally by the module author:

	package Module::Build::Action;
	our %ActionClassMap =3D
	  (
	   Build =3D> 'My::Action::Build',
	   ...
	  );

Externally, that hash is populated by a 'register' method like the one=20=

you had above:

	package My::Module::Action::Build;
	use base qw( Modle::Build::Action::Build );
	Module::Build::Action->register( build =3D> __PACKAGE__ );
	# or alternatively:
	__PACKAGE__->register( 'build' );

2. Search packages.
This option is potentially less work, but not as flexible in naming=20
convention - the idea is you have a rule for naming action classes=20
under a namespace, and an ordered list of packages to search.  For=20
example:

	# assuming a 'ucfirst' rule:
	$class       =3D ucfirst( $action ); # 'build' =3D> 'Build'
	@search_pkgs =3D qw( Module::Build::Action );

	foreach my $pkg ( @search_pkgs ) {
		$pkg .=3D "::$class";
		return $pkg if $pkg->can( 'new' );
		eval "require $pkg";
		return $pkg unless $@;
	}

	die "couldn't find action $action\n";



>>>  Each action knows what parameters it accepts and can display its=20
>>> own help info. There could be a helper class for generating actions=20=

>>> and linking them by dependencies, i.e.
>>>
>>> my $action =3D new M::B::ACTION::Builder(
>>>   name =3D> 'My_lib',
>>>   code =3D> sub {},
>>>   ...
>>> );
>> Dunno if that's needed - M::B already does it.
>
> Do you mean the subclass() method? In the way I'm describing, you=20
> would subclass on an action by action basis rather than subclass M::B;=20=

> in fact, you would probably rarely if ever need to subclass M::B=20
> itself.

Yeah, I think I missed the point last time :).  Gotcha now.


>>> my $top =3D new M::B::ACTION::Builtin( name =3D> '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 =3D new M::B::Action::find_action( name =3D> '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=20
external to the Actions themselves, eh?  Well, it's not what I was=20
thinking but it could work.

Still, after a bit of thought I'd say keep it simple and sub-class if=20
ever you want to change the dependency tree.  Which is not as flexible=20=

when you're writing Build.PL's, but it does mean less work for the=20
person implementing/maintaining M::B's action dispatching code.

-Steve

Re: [Module::Build] Array form of do_system causing problems

[Stephen J. S. <sj...@kh...>]

On Thu, 2003-10-16 at 20:36, Ken Williams wrote:
> On Thursday, October 16, 2003, at 01:40  PM, Chris Dolan wrote:
> > I build packages like this:
> >    Build dist gzip="gzip -f --best"
> 
> The 'gzip' parameter is intended to be the path to gzip, not the path 
> plus arguments.  But if it's important to take arguments, that could be 
> added.

An alias (alias gzbest='gzip -f --best') or a script that calls gzip
will work right?  Is that too inconvenient?  It wouldn't be to me, I
don't think.

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

[Ken W. <ke...@ma...>]

On Thursday, October 16, 2003, at 09:57  PM, 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:
>>> There is another issue here in that the list of actions is growing 
>>> quite large, and M::B is (IMHO) turning into a large monolithic 
>>> module. Would it be worth the effort to re-architect actions, so 
>>> that they are plug-ins (M::B::ACTION::html, M::B::ACTION::dist). 
>>> This would keep M::B from becoming monolithic and would allow others 
>>> to develop plug-ins to expand functionality without requiring 
>>> invasive code changes.
>> Yes, M::B: is becoming quite monolithic.  So was MakeMaker.  The main 
>> difference I find between the two is that M::B is much easier to 
>> read, understand and extend.
>
> I didn't realize until now that my original choice of words may have 
> been misconstrued as an insulting remark--That was not my intent. I 
> meant monolithic in the sense that most of the code is in a single 
> file/class (M::B::Base) that it is growing quite large, and it is not 
> likely to get smaller. I didn't intend it as an insult or as any kind 
> of judgemental statement, just as an observation.

Oh, I took no offense, and I think I would actually make the same 
criticism myself.  The monolithic nature of M::B is something I've been 
thinking about a lot (well, maybe just "some") lately.

A basic design stress in designing M::B was the following conflict:

  A) it should be easy to subclass, meaning that all methods should be 
part of a single class hierarchy

  B) it should be scalable, meaning that multiple classes should 
interrelate to accomplish tasks, and the user should be able to swap 
out different parts of the system with their own parts.

In the end I chose A).  A system like Mason uses B).  I think the trick 
now is to get the benefits of A) while incorporating some of the 
benefits of B), and I think a plug-in system could do that nicely.


>
> I don't know that I would describe MakeMaker as monolithic. Michael 
> Schwern has done a great job of cleaning it up. It's main problem is 
> that it is limited to the underlying tool--make, and to it's different 
> versions, implementations, and platforms.

Yeah, MakeMaker is sort of multi-monolithic.  Or Stonehengian.  ;-)

  -Ken

Re: [Module::Build] ANNOUNCE: 0.21 released

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

On 10/15/2003 11:22 PM, Randy W. Sims wrote:
> There is also something going on at t/runthrough.t #20. I think I 
> upgraded the Tar module recently, that may have something to do with it 
> as it has always been troublesome on Windows.
> 
> Randy.

This chatter comes from tring to add directories to the tarball. 
grepping before passing the list to create_archive() fixes this problem.

sub make_tarball {
   my ($self, $dir) = @_;

   require Archive::Tar;
   my $files = $self->rscan_dir($dir);

   print "Creating $dir.tar.gz\n";
   Archive::Tar->create_archive("$dir.tar.gz", 1, grep !-d, @$files);
}

Randy.

Re: [Module::Build] Array form of do_system causing problems

[Chris D. <ch...@cl...>]

I'm pretty sure that the alias won't work, since system() doesn't go 
through the shell.  However, a simple script should be a good enough 
workaround for me, so I'll use that for now.  But, we should keep a 
mental note to revisit this.  Others like me coming from the Makefile 
world will expect this to work.

Chris

On Thursday, October 16, 2003, at 09:04  PM, Stephen J. Smith wrote:

> On Thu, 2003-10-16 at 20:36, Ken Williams wrote:
>> On Thursday, October 16, 2003, at 01:40  PM, Chris Dolan wrote:
>>> I build packages like this:
>>>    Build dist gzip="gzip -f --best"
>>
>> The 'gzip' parameter is intended to be the path to gzip, not the path
>> plus arguments.  But if it's important to take arguments, that could 
>> be
>> added.
>
> An alias (alias gzbest='gzip -f --best') or a script that calls gzip
> will work right?  Is that too inconvenient?  It wouldn't be to me, I
> don't think.

Re: [Module::Build] Array form of do_system causing problems

[Chris D. <ch...@cl...>]

On Thursday, October 16, 2003, at 07:36  PM, Ken Williams wrote:

> On Thursday, October 16, 2003, at 01:40  PM, Chris Dolan wrote:
>
>> Perhaps do_system should check if there are spaces in the name of the 
>> executable?  That might not be the right thing on a Windows box, or 
>> any other platform where spaces commonly occur in directory names...
>
> Yeah, and it specifically does the wrong thing if your gzip is
> something like "/My Macintosh/My Stuff/gzip".

Hmm, I thought about putting "m{\s[^/]+$}" in the patch, but it had 
occurred to me that "perl -Iblib/lib" would be broken by that...

> The 'gzip' parameter is intended to be the path to gzip, not the path 
> plus arguments.  But if it's important to take arguments, that could 
> be added.

That makes sense.  I'm just used to Makefiles, where you can add 
cmdline args to gcc via the "make CC='gcc -Ddebug'" syntax, for example.

Anyone else have any good ideas how to handle user cmdline options 
while still maintaining the simplicity of the array version of system()?

Chris

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

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

Thanks for the discussion; It has caused me think this through a little 
more thoroughly. But the thoughts below should still be considered 
idealizations and may differ from the possible or practical. ;)

On 10/16/2003 6:50 AM, Steve Purkis wrote:
> On Thursday, October 16, 2003, at 12:06  am, Randy W. Sims wrote:
> 
>> There is another issue here in that the list of actions is growing 
>> quite large, and M::B is (IMHO) turning into a large monolithic 
>> module. Would it be worth the effort to re-architect actions, so that 
>> they are plug-ins (M::B::ACTION::html, M::B::ACTION::dist). This would 
>> keep M::B from becoming monolithic and would allow others to develop 
>> plug-ins to expand functionality without requiring invasive code changes.
> 
> 
> Yes, M::B: is becoming quite monolithic.  So was MakeMaker.  The main 
> difference I find between the two is that M::B is much easier to read, 
> understand and extend.

I didn't realize until now that my original choice of words may have 
been misconstrued as an insulting remark--That was not my intent. I 
meant monolithic in the sense that most of the code is in a single 
file/class (M::B::Base) that it is growing quite large, and it is not 
likely to get smaller. I didn't intend it as an insult or as any kind of 
judgemental statement, just as an observation.

I don't know that I would describe MakeMaker as monolithic. Michael 
Schwern has done a great job of cleaning it up. It's main problem is 
that it is limited to the underlying tool--make, and to it's different 
versions, implementations, and platforms.

> Splitting out the actions is not a bad idea - I bounced a similar one 
> around with some friends in the past:
> 
>     package My::Action;
> 
>     use base qw( Module::Build::Action );
>     use constant depends_on => qw( foo, bar );
> 
>     sub builder { }    # the parent M::B obj
> 
>     sub check_dependencies {
>         ...
>     }
> 
>     sub execute {
>         ...
>     }
> 
> There are a few problems with these ideas: how do you write platform 
> specific code?  One answer is to sub-class each action, or write a 
> method for each platform in the action's class.  That could work, but it 
> could also get a bit hairy.

The idea(l) is that M::B provide as much as possible an API for the 
action plugins that is platform independent. If there are still OS 
differences and they are small, they can be put inline. Otherwise, you 
would create subclasses that handled the differences and use the 'base' 
class as a proxy, forwarding the calls to the appropriate 'subclass'.

i.e. if you write an action, say for reporting build status to 
cpan-testers called M::B::Action::Reports. If there are differnces 
between *nix systems & Windows, you'd create classes 
M::B::Action::Reports::Unix & M::B::Action::Reports::Windows. Now, in 
M::B::Action::Reports you'd write stub functions that determinse the 
appropriate subclass to call based on OS and forward the call to the 
real function in the determined subclass.

> Then, how do you access commonly used methods?  A solution might be to 
> bung all these methods in a common place that everybody inherits from, 
> say M::B::Common:
> 
>     M::B::Common
>         |
>         +- M::B::Base
>         |
>         +- M::B::Action
>               |
>               +- M::B::Action::Foo

Again, the common methods would become part of M::B's API for actions. 
(Nit: It's a bad idea to subclass just to share code.)

> And, how do you subclass actions?  If I want to write my own 'install' 
> action, how do I do it?  At the moment, I sub-class M::B and do it 
> there.  Sub-classing each action is easy, but how do you get M::B to use 
> them?  One way is to say M::B::Base must have stub methods for each 
> action so that they can be overridden.

As an Build.PL author, you would do one of two things. 1) You'd use a 
helper class, something like

my $action = new M::B::Action::Builder(
   name => 'install',
   code => sub {...},
   help => 'A help message to display for users.'
);

M::B::Action::register( $action );

or 2) You'd create an inline class and register it:

package MY::Action::install;
use Module::Build::Action::Install;
use vars qw(@ISA);
@ISA = qw(Module::Build::Action::Install);
sub new { return Module::Build::Action::register( bless \my $arse ) }
sub ACTION_install { ... }

package main
new MY::Action::install;
...

> I think they all stem from the fact that M::B was not written with this 
> design in mind, so it would take a lot of effort to refactor things.  It 
> certainly would involve a *lot* of changes, and little (if any) 
> backwards compatibility.  There is potentially a huge gain as far as 
> simplicity is concerned, but it may be more work than it's worth.

Yeah, I have no doubt it would be difficult to change, but M::B is not 
going to get smaller. So, any refactoring is best done sooner than later.

> That said...
> 
>> This is only half thought-out, so I'm not sure if it's practical. For 
>> example, I don't know how easy it would be to come up with an 
>> interface so that actions could get info from M::B without digging 
>> into the internals.
> 
> 
> Making them plugins is a good idea, but it's even more complicated.
> 
> 
>> <thinking out loud>
>>
>> Each module would contain one or more actions.
> 
> 
> I'd limit it to one a package.  That way you can get the action name 
> from the package name itself:
> 
>     'build' => M::B::Action::Build

It would be more convenient to allow multiple related actions to share a 
file so that they can share common functions/data. Also, it's best if 
they do not share the name because the most appropriate name for an 
action might be a perl keyword. The module should have a descriptive 
name appropriate for the actions it contains. The actions 
(packages/classes) themselves should probably follow the current 
standard of prefacing them with 'ACTION_' to avoid conflicts.

>>  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. ???

> Then it would find your actions first.  If you have 1 action per 
> package, then M::B already knows what it does.  So eventually you build 
> a map:
> 
>     $build->{ActionClassMap} = {
>         Build   => 'My::Action::Build'
>         Install => 'M::B::Action::Install'
>     };
> 
> Then to dispatch, you do something like:
> 
>     sub dispatch {
>         my $self   = shift;
>         my $action = shift;
>         my $aclass = $self->{ActionClassMap}->{$action} || die;
>         $aclass->new->builder( $self )->check_dependencies->execute;
>     }
> 
> 
>>  Each action knows what parameters it accepts and can display its own 
>> help info. There could be a helper class for generating actions and 
>> linking them by dependencies, i.e.
>>
>> my $action = new M::B::ACTION::Builder(
>>   name => 'My_lib',
>>   code => sub {},
>>   ...
>> );
> 
> 
> Dunno if that's needed - M::B already does it.

Do you mean the subclass() method? In the way I'm describing, you would 
subclass on an action by action basis rather than subclass M::B; in 
fact, you would probably rarely if ever need to subclass M::B itself.

>> 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.

> Food for thought...
> 
> -Steve
> 

Randy.