Ken Williams wrote:
On Jan 3, 2005, at 11:55 PM, Randy W. Sims wrote:
Specific goals:
1. PM_Info.pm - Reads a module (or script) in a single pass gathering
information important to M::B. This is mostly done; see attached.
I think you can go ahead and commit this. I'd recommend a couple
changes, though:
1) Rename the class to M::B::ModuleFile or somesuch - the name PM_Info
smacks of a C struct or a Java utility class or something.
2) Since it'll be part of the M::B distribution and it'll be used
fairly frequently, it can just be loaded at startup with use() instead
of as-needed with require().
Ok, changes made.
Regarding the other classes you suggested, I think none of them have
quite as compelling an argument as this one - but maybe that's because
code actually exists for this one. =)
For M::B::MyPerlConfg, there isn't a lot of advantage. What I have in
mind is pulling some of the methods relating to the users installed perl
into this module: find_perl_interpreter, perl_version, etc.
Also, to have M::B access %Config thru this module, for which I have a
draft implementation (though not integrated). It only stores values that
are explicitly set. If you reference a value that has not been set, it
then checks %Config. So if we serialize only the values stored by
M::B::MyPerlConfig in _build/build_params, we can save about 40+k of
disk as well as runtime memory.
For M::B::OptionManager, I was wanting to move all of the property
handling routines into one place and out of the way of M::B proper. I
haven't thought too much beyond that goal. But one thing I'd really like
to find a way to add is the ability to validate commandline args, so I
don't keep doing things like
perl Build test test_files=t/basic.t version=1
(should've been verbose=1)
Like I kept doing the other night when I was playing with the versioning
code. Could also include per action arguments too, including the
'Build.PL' action although that action should accept all options without
complaint for compatability with the way CPANPLUS invokes M::B. Per
action options would be, for example, 'codebase' which is only valid for
the ppm & ppd actions and doesn't make sense anywhere else.
The above two classes may also simplify the process of serializing M::B
state. Hopefully, it will also greatly reduce the size of M::B::Base.
The goal of the other modules I mentioned are more organizational than
anything, putting related stuff together. And shrinking the size of
M::B::Base, so there is less to think about when making modifications.
Of course, I also want to avoid breaking it up into too many pieces.
I'm probably doing a terrible job of describing this. If there are no
outright objections, I'll just write the code and then let you decide if
it's acceptable. I'll throw it away if I have to. =)
There is some shared code between M::B & ExtUtils::CBuilder that could
be refactored into a common module they both depend on: running perl
scripts, parsing command lines, etc.
Yeah, it's true. That stuff could be factored out. One reason I
haven't done it already is that the common code lacks a clear, coherent
identity - it's just kind of a collection of utility methods.
Yeah, it's not clear what abstraction to use. I had breifly entertained
the idea of putting in something like ExtUtils::Shell, or maybe sneaking
it into ExtUtils::Command or Text::ParseWords. But they do feel a bit
forced. Not sure what to do here? It's kind of a pain having the code in
two places. Even now they are out-of-sync -- eg, the Windows
C<split_like_shell()> function.
Another reason is that the new module would also have to have the same
inheritance-by-platform-type structure that M::B and EU::CBuilder have,
and I've been a bit loathe to replicate that again. Maybe *that* could
be factored out somehow, actually. ;-)
Hmm, I had that put in M::B::MyPerlConfig.pm (No, I don't like that name
either); I had forgot that it was also shared with EU::CBuilder...
Anyway, before committing anything, I wanted to sound out.
Additionally, I was wondering if the refactoring should take place in
a branch until it's complete and agreeable.
For the patch you've already written, I think it can go right against
HEAD. For other stuff let's work it out case-by-case.
OK.
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
|
