Re: [Module::Build] Extending M::B::Platform::* and issues with "provides"

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

Hi Chris,

On Tuesday, October 7, 2003, at 12:58  PM, Chris Dolan wrote:

> I'm working on a subclass of Module::Build that is intended to package 
> non-Perl material.  I've found M::B to be modular enough that this is 
> feasible without hacking *too* deeply (bravo to Ken and others!).  One 
> aspect of this project includes adding platform-dependent compilation 
> routines.  I accomplished this by simply saying something like:
>
> -------- lib/Module/Build/Foo.pm -----------
> package Module::Build::Foo;
> our @ISA=qw(Module::Build);
> ...
> sub ACTION_foo {
>   my $self = shift;
>   $self->compile_foo($_) for (@{ $self->find_foo_files })
> }
> ...
> package Module::Build::Base;
> sub compile_foo {
>   print "Compiling foo is not supported on this platform\n';
> }
> package Module::Build::Platform::darwin;
> sub compile_foo {
>   my ($self, $file) = @_;
>   $self->do_system("compileFoo", $file);
> }
> 1;
> ---------------------------------------------
>
> This seems to work great with one exception:  META.yml now contains 
> the following lines
>
> ---------------------------------------
> provides:
>   Module::Build::Base:
>     file: lib/Module/Build/Foo.pm
>     version: 0.10
>   Module::Build::Foo:
>     file: lib/Module/Build/Foo.pm
>     version: 0.10
>   Module::Build::Platform::darwin:
>     file: lib/Module/Build/Foo.pm
>     version: 0.10
> ---------------------------------------
>
> I think this is bad thing, yes?  I'm not providing those packages; I'm 
> just hacking them for my particular environment.  Questions:
>
> 1) Is there a better way to add platform-specific extensions to M::B 
> subclasses without hacking ::Base and ::Platform::*?

At this point, unfortunately not.  One project for the future will be 
to move the compilation stuff out to a new standalone package (probably 
called Module::CBuilder or something), and make that package extensible.


> 2) Would explicitly declaring
>    sub Module::Build::Base::compile_foo { ... }
> be better?

For perl it's wouldn't make any difference, but for Module::Build it 
would be better because those subroutines wouldn't show up in your 
'provides' hash anymore, so yeah, I guess that's a good idea.


>
> 3) Is there a good way to tell ACTION_distmeta not to include those 
> hacked packages in the provides hash?

Currently not.  We may end up adding a 'provides_skip' key or something 
where you could tell M::B not to include certain packages or entire 
namespaces in the 'provides' listing.

> P.S. In M::B v0.20, ACTION_distmeta has an out-of-date warning message 
> about Module::Info.  I happened to notice that in my research for the 
> above questions.  I didn't check CVS to see if it's already been > fixed.

Aha, thanks.  I've removed it.

  -Ken