module-build-general

[Module::Build] [RFC] [PATCH] Action plugins

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

Hi Ken,

Attached is a /prototype/ (about the 3rd one) for plugin actions. In the 
prototype all plugin action names are prefixed with an 'x' so that they 
don't override the current actions. The only actions implemented are 
'xhelp' and 'xmanifest', though templates are inplace for the others. 
See perldoc lib/Module/Build/Action.pm for an extremely brief user view 
of creating plugins.

The only things worth looking at right now are Module::Build::Action and 
Module::Build::Action::Help. M::B::Action builds up a list of plugins 
and some info about them. We highjack the dispatch call in M::B::Base to 
our own in M::B::Action which looks up dependencies and executes them 
recursively. This is of course different than the 
M::B::Base::depends_on() immediate execution method of handling 
dependencies, but it is more flexible and will allow builders (modules 
that aid in creating new actions) to work. When we highjack the dispatch 
call we also pass in $self->{args} so that actions can process thier own 
arguments.

This is a prototype and contains some no no's, but it hopefully provides 
enough to comment on. This is about as far as I can go without being 
invasive, and I wanted to get feedback before before proceeding. It is a 
prototype, so if you think it should be thrown out, that's fine. 
Otherwise, I'll start cleaning it up and either turn it over to you if 
you want, or continue (I'm a little reluctant to do something as 
invasive as this will be and create the plugin API, but I'm more than 
willing to help:).

Hope this is helpfull.

Randy.

Re: [Module::Build] [RFC] [PATCH] Action plugins

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

As I work on this, I'll keep updated versions at 
<http://www.thepierianspring.org/patch.gz>.

Randy.

Re: [Module::Build] [RFC] [PATCH] Action plugins

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

On 11/30/2003 9:15 AM, Randy W. Sims wrote:
> 
> This is a prototype and contains some no no's, but it hopefully provides 
> enough to comment on. This is about as far as I can go without being 
> invasive, and I wanted to get feedback before before proceeding. It is a 
> prototype, so if you think it should be thrown out, that's fine. 
> Otherwise, I'll start cleaning it up and either turn it over to you if 
> you want, or continue (I'm a little reluctant to do something as 
> invasive as this will be and create the plugin API, but I'm more than 
> willing to help:).
> 
> Hope this is helpfull.
> 
> Randy.


Well, no one is commenting. That's not good. Perhaps I should list
some of the benefits of this plugin architecture:

* Users can write and distribute their own custom actions.

* Module authors can simplify their Build.PL files by writing their
   custom actions as plugins, placing them in
   'inc/Module/Build/Action/' and adding a 'use lib qw(inc);' before they
   'use Module::Build'.

* Sites can customize installs in a similar manner as above by setting
   the PERL5LIB environment variable to point to their custom overrides
   of builtin actions.

* Action builders can make it extremely easy to create simple
   actions.

* Allows for an elegant solution to the current architectural issues
   regarding compiling/linking in Module::Build. (This is my primary
   goal in creating this prototype.)

* Simplifies Module::Build, providing better encapsulation for its
   different functional areas.

Ken, should I drop this? I would like to help where I can. M::B is a
project I believe very strongly in, but someone needs to tell me where
(or if) I can help.

I've got a short list of things I'd like to contribute: plugins,
compiler stuff, adding trace info (like make --debug), nested builds,
h2xs M::B support, support for building modules outside the source
directory. But this is your project, and I don't want to get in the
way. Just tell me where to go. ;)

Regards,
Randy.

Re: [Module::Build] [RFC] [PATCH] Action plugins

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

On Tuesday, December 2, 2003, at 06:18  PM, Randy W. Sims wrote:

> On 11/30/2003 9:15 AM, Randy W. Sims wrote:
>> This is a prototype and contains some no no's, but it hopefully 
>> provides enough to comment on. This is about as far as I can go 
>> without being invasive, and I wanted to get feedback before before 
>> proceeding. It is a prototype, so if you think it should be thrown 
>> out, that's fine. Otherwise, I'll start cleaning it up and either 
>> turn it over to you if you want, or continue (I'm a little reluctant 
>> to do something as invasive as this will be and create the plugin 
>> API, but I'm more than willing to help:).
>> Hope this is helpfull.
>> Randy.
>
>
> Well, no one is commenting. That's not good.

Hi Randy,

I'm not trying to ignore you, I swear - I just keep wanting to make a 
little prototype of what I had in mind for a plugin architecture too, 
and I thought it might be better to do it independently first and then 
we can compare advantages & disadvantages of each.

Several of the points below are advantages of any plugin scheme we 
settle on, and I'm still quite keen on getting *something* done.  If I 
can't get off (or on, I guess) my butt and write some code of my own, 
my default action will be to just apply your patches.  I do very much 
appreciate the time you've spent.

Also, have you had a chance to take a look at ExtUtils::CBuilder?  How 
do you see it fitting in with a plugin scheme?  My goal with it was to 
make something that would be generically useful, not just as a plugin 
for Module::Build.


> Perhaps I should list
> some of the benefits of this plugin architecture:
>
> * Users can write and distribute their own custom actions.
>
> * Module authors can simplify their Build.PL files by writing their
>   custom actions as plugins, placing them in
>   'inc/Module/Build/Action/' and adding a 'use lib qw(inc);' before 
> they
>   'use Module::Build'.
>
> * Sites can customize installs in a similar manner as above by setting
>   the PERL5LIB environment variable to point to their custom overrides
>   of builtin actions.
>
> * Action builders can make it extremely easy to create simple
>   actions.
>
> * Allows for an elegant solution to the current architectural issues
>   regarding compiling/linking in Module::Build. (This is my primary
>   goal in creating this prototype.)
>
> * Simplifies Module::Build, providing better encapsulation for its
>   different functional areas.
>
> Ken, should I drop this? I would like to help where I can. M::B is a
> project I believe very strongly in, but someone needs to tell me where
> (or if) I can help.
>
> I've got a short list of things I'd like to contribute: plugins,
> compiler stuff, adding trace info (like make --debug), nested builds,
> h2xs M::B support, support for building modules outside the source
> directory. But this is your project, and I don't want to get in the
> way. Just tell me where to go. ;)
>
> Regards,
> Randy.
>

Re: [Module::Build] [RFC] [PATCH] Action plugins

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

On 12/3/2003 11:01 PM, Ken Williams wrote:

  > Hi Randy,
> 
> I'm not trying to ignore you, I swear - I just keep wanting to make a 
> little prototype of what I had in mind for a plugin architecture too, 
> and I thought it might be better to do it independently first and then 
> we can compare advantages & disadvantages of each.

No problem. I guess some people do have a life outside of writing code ;).

> Several of the points below are advantages of any plugin scheme we 
> settle on, and I'm still quite keen on getting *something* done.  If I 
> can't get off (or on, I guess) my butt and write some code of my own, my 

Yeah, I don't claim my solution is the best. In fact, it's really not 
much like what I originally planned; it evolved quite a bit into what it 
is now. Like I said before, I'm mainly thinking about the 
compiling/linking code, and I see plugins as an elegant solution to the 
current problems...

> default action will be to just apply your patches.

Please don't apply my patch; it's still a prototype, and I need to clean 
it up a bit. I need to reorganize it by splitting M::B::Action, so that 
M::B::Action remains a base class, and the other /stuff/ gets put into 
something like M::B::ActionManager which will be responsible for 
scanning plugins and dispatching actions.

 >  I do very much appreciate the time you've spent.
 >
> Also, have you had a chance to take a look at ExtUtils::CBuilder?  How 
> do you see it fitting in with a plugin scheme?  My goal with it was to 
> make something that would be generically useful, not just as a plugin 
> for Module::Build.

I will try to post something this evening when I have more time to put 
my thoughts together into something coherent. =)

Regards,
Randy.

Re: [Module::Build] [RFC] [PATCH] Action plugins

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

On 12/3/2003 11:01 PM, Ken Williams wrote:
> 
> Also, have you had a chance to take a look at ExtUtils::CBuilder?  How 
> do you see it fitting in with a plugin scheme?  My goal with it was to 
> make something that would be generically useful, not just as a plugin 
> for Module::Build.
> 

I've been thinking a little more about EU::CBuilder. I've come up with 
the following list of tasks that it must be able to accomplish as far as 
providing services to M::B. Do you see anything missing or extraneous?

* determine if compiler/linker are present and configured.

* preprocess XS files to c/c++ source files.

* (optionally) run the c/c++ source files through the cpp preprocessor 
and output the results for debugging help.

* compile the c/c++ source files for use in a perl dynamic library. 
(what it does now)

* compile the c/c++ source files for use in a statically linked in 
library (main differentiator here is the exclusion of 
$Config{cccdlflags} when compiling).

* compile the c/c++ source files for use in a non-perl library (in this 
case we don't need to know if it's for a static or dynamic library).

* generate symbolic export definition file for the library if it's a 
perl dynamic library (prelink).

* link object files into a perl dynamic library.

* link object files into a non-perl dynamic library.

* link object files into a static library and then link with perl 
(makeaperl).

* link object files into a non-perl static library. (ex. Compress::Zlib)

* link object files into an executable.

* track temporaries and output files.

(It's kinda neat working with a (new pet) ferret running around on the 
desk except when she starts playing with the (non-pet) mouse while I'm 
trying to type. Oh, and she also has this annoying habbit of taking a 
dump on the corner of the desk which isn't so bad as far as cleaning up, 
but the dang thang won't lick herself. I don't know what to think of an 
animal that want lick itself clean after going to the pot. I don't won't 
to pick her up and get... stuff all over me... ick.)

Regards,
Randy.

PS: There seems to be something wrong with the list--missing messages, 
archives out of sync, etc. Is this a sourceforge problem?

Re: [Module::Build] [RFC] [PATCH] Action plugins

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

Resending: this never made it to the list. (originally sent 12/4/2003 
9:06 PM)

On 12/3/2003 11:01 PM, Ken Williams wrote:
> Also, have you had a chance to take a look at ExtUtils::CBuilder?  How 
> do you see it fitting in with a plugin scheme?  My goal with it was to 
> make something that would be generically useful, not just as a plugin 
> for Module::Build.

I've /briefly/ looked at EU::CBuilder (btw, there is a product, a
compiler with that name <http://www.borland.com/cbuilderx/>). Lifting
that code out of M::B should make things much easier to manage. It is
going to need to change a good bit... mostly just parameterizing on
whether creating a static or dynamic library (or executable?) and on
whether or not to include all the perl defines, etc. The reason for the
latter is modules like Compress::Zlib that includes the source for and
build zlib and links to it. zlib would not need to see any of the perl
specific stuff.

As far as fitting in with the plugin scheme, I haven't tried to look far
enough to be able to nail down an interface between the two. I'm mostly
looking from the top-down. I'm imagining that there will be some action
builders that make it easy to construct actions to accomplish certain
goals. The relevant builder here would be the library builder which
would be given a list of source files, and it would then create all the
neccessary actions and dependencies.

my $lib = Module::Build::Action::Builder->new_library(
   output   => 'mylib',
   sources  => [ qw(file1.c file2.c file3.c) ],
   use_perl => 1, # include perl specific stuff
);

Under the hood it would create an action named 'mylib', generate
depenecies on the object files, create actions for each of the object
files with a dependency on its respective source file, etc. Then you
would say

Module::Build::Action::by_name('code')->add_dependency($lib);

to add it as a dependency of the code action.

This design resulted in my decision to implement the prototype the way I
did. Specifically scanning for plugins at startup to generate a list of
action which can then be modified at runtime. Scanning at startup
initially had me concered because of a delayed startup, but testing on
an old 466 Mhz pentium has nearly convinced me that it won't be a problem.

As far as how the above will interface with EU::CBuilder, I'm not
entirely sure yet. I'm hoping it will be obvious when we get there. =)

Randy.

He He, this interesting(?) article just showed up on
<http://news.google.com/>:

<http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2003/12/05/nfossil05.xml&sSheet=/portal/2003/12/05/ixportal.html>