On Mon, Nov 04, 2002 at 11:54:27PM +0000, Soren Andersen wrote:
> I wrote that i had been "hacking on MakeMaker". To quell or alternately
> to amplify whatever consternation that statement might have engendered,
> I will now briefly outline what sort of thing i have been trying to do.
>
> Without having properly asked for comments (RFC'ing) i've named a
> module-set. The name is to be "ExtUtils::ExoBuild". Exo == 'external,
> outside', as in 'exoskeleton' [familiar to those readers who are {a}
> into mecha (a type of manga/anime) {b} study arthropods (one of the
> dominant and arguably most successful 'templates' for animal life on our
> planet) or {c} ARE arthropods]. 'ExoBuild' means 'build a perl extension
> [module] outside of the directory where the source distro is located.'
Suggestion: Don't use ExtUtils:: use Module::. ExtUtils is really the wrong
place for MakeMaker, its there by historical accident. ExtUtils is really
for things which interface with "External Utilities" like other compilers
(for example, ExtUtils::F77 interfaces with a Fortran77 compiler).
Technically, MakeMaker works with make, an external utility, but what it's
really about is modules. And modules should really be named for what
they're used for, not what they're technically about.
So stuff that's for building modules should go into Module::, regardless of
how it does it.
> What I need help with is the inheritance scheme for MakeMaker as a whole
> (which i think is very complex and convoluted -- because the problem
> domain is large, not because the work Schwern et al have done is badly
> done) and with other issues.
You might want to start by reading this:
"The provisional ExtUtils::MakeMaker class hierarchy"
http://archive.develooper.com/makemaker@;perl.org/msg00134.html
It ain't pretty.
> To begin with, i'd like to achieve a way in which i might be able to
> inherit methods from the MM_Unix and subordinate pals while able (of
> course) to override certain methods with ones located in my own
> module(s -- there are two of them).
Best bet at the moment is to look at how something like ExtUtils::MM_DOS
does it and then roll with the punches when it changes.
> The first lines of ExtUtils/ExoBuild.pm contain the following:
>
> -----------------------8<------------------------------------------
> package ExtUtils::ExoBuild;
>
> use 5.006;
> use strict;
> use warnings;
> use Carp;
> require Exporter;
> use vars qw( @ISA $VERSION $Verbose);
> use ExtUtils::ExoBuild::ExoTools qw(
> &check_hints &mv_all_methods &parse_args &neatvalue );
>
> require ExtUtils::MM; #dangerous -- may go away someday.
> use ExtUtils::MakeMaker; #this is dubious, only testing will tell.
> use ExtUtils::MM_Any; #generic platform-agnostic utilities, we'll need a
> few.
> $Verbose = 2; #debugging
> @ISA = qw(ExtUtils::ExoBuild::ExoTools ExtUtils::MM);
> -----------------------8<------------------------------------------
>
> I recognize that i may not want to be exporting anything and that may
> disappear. I started with the generic module template output for me by
> h2xs and am modifying that as i learn along the way.
>
> Q: Is it accurate to state that MakeMaker is in fact a mix of OO and
> non-OO perl code? To start with, data passed when we do 'perl
> Makefile.PL' is a hash that gets subjected to non-OO subroutines like
> _validate_att().
It's primarily OO, but I don't draw a hard line between procedural and
object-oriented code. _verify_att() didn't need an object so I didn't make
it object oriented. However, this might have been a mistake since I believe
_verify_att needs to be made overridable.
> Am I correct in this perception, that a lot of what
> might be called pre-processing and setup takes place before what is to
> become the build configuration, is blessed into any kind of object?
No, just _verify_att() and that's because it validates the arguments to
WriteMakefile(). But I might move it inside new() instead.
> To back up a little, my intention is to create modules to do exobuilds
> because i have assumed that direct patches to add such radically new
> functionality to the existing MakeMaker family of modules would not be
> welcomed. I could be wrong.
You're not. Module::Build is down the hall, third door on the left with the
glowing fog seeping out from under the doorjam. I encourage people who want
to bolt new functionality onto MakeMaker to consider Module::Build instead.
> My second, "accessory" module is "ExtUtils::ExoBuild::ExoTools" and it
> exists to try to replace some methods in the MM_Any and MM_.* modules. i
> have, for example, a replacement pm_to_blib() sub in that module, but my
> test runs show that it isn't being invoked in overrid-ship of the one in
> the existing MM_.*.
MakeMaker screws around with its class hierarchy at run-time depending on
what OS you're on. It picks an MM_* module inside ExtUtils::MM to inherit
from. It's not really designed to have any other things plugged into it and
the logic is not inside a subroutine. I'm not sure what you can do about
that, MakeMaker isn't really designed to be externally subclassed.
The first lines of that module follow:
> -----------------------8<------------------------------------------
> package ExtUtils::ExoBuild::ExoTools;
>
> require Exporter;
> require ExtUtils::MM_Any;
> require ExtUtils::MM_Unix;
> use File::Spec;
> our @ISA = qw(ExtUtils::MM_Any ExtUtils::MM_Unix Exporter);
>
> use vars qw($VERSION $unbusy_Makefile $Verbose @EXPORT_OK);
> @EXPORT_OK = qw{ &check_hints &mv_all_methods &parse_args &neatvalue };
> $Verbose = $ExtUtils::ExoBuild::Verbose;
> -----------------------8<------------------------------------------
>
> I could go on and on, but I can't ;-). Maybe that's for the best. Let
> this serve as a introduction to what i am interested in and maybe
> further explanation and exposition can be added later.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Don't treat people this way! Milk & Cheese are indestructible! You are not!
