Hi Dominique, thanks for your comments & suggestions.
On Nov 18, 2005, at 3:05 AM, Dominique Quatravaux wrote:
Well I did some overloading of M::B, including but not limited to my
Emacs debugger contrib
(http://sourceforge.net/mailarchive/forum.php?
thread_id=8909497&forum_id=10905,
no replies so far although I understand about the pressing issues of
getting 0.28 out
Sorry for dropping your message, I think it's a useful patch (though
the sourceforge mail archiver's formatting is pretty useless for code -
it ends up with things like: "For the developper's comfort, if only one
test is specified in this way, I assumes that I mode is wanted (see
L).") I'll respond to that message separately.
Anyway I needed access to the following internals:
* overloaded ->_startperl() to have ./Build chdir() into the right
place first thing in the morning (working around RT #15920);
I think that's a good suggestion. Anyone have any objections to it?
The basic idea is that instead of complaining about being run from the
wrong directory, the 'Build' script should simply
chdir($the_right_directory)||die($gack) at its startup.
* overloaded ->ACTION_distmeta() to change the contents of
META.yml in a very kludgy way (I open the file and alter it
in-place after it's created). I wish there were an overloadable
method that just computes the text contents of META.yml (just
like ->_startperl());
I'm hesitant to treat the META text as one giant string, it smacks of
the string manipulations people have to do in MakeMaker. Do you know
about the prepare_metadata() method that you can override? It's now
been documented in M::B::Authoring.
* had to reach inside $builder->{args}->{ARGV} to be able to say
"./Build test t/script1.t t/script2.t" to run a subset of the
tests. ->args() is not what I want because my args are not
key/value pairs;
The official way to run a subset of the tests is a little more verbose,
but works out of the box: "./Build test --test_files t/script1.t
--test_files t/script2.t" . I have a nice short alias in my shell for
running single test files:
% which t
t: aliased to Build test --test_files
* fiddled with $builder->{properties}->{verbose} to DWIM, I'd like
to have an accessor there.
It's actually already got an accessor, $build->verbose or
$build->verbose($value).
When the return value is for information only (e.g.
- ->check_installed_status()) it doesn't matter IMO. Conversely, when
the altering by caller of the returned reference is intended to have
an effect (e.g. my ->{args} case), I think it's a good idea to
encapsulate it (plus it can be made a zero-maintenance thing using
some AUTOLOAD trickery). This way one can repent later and add
value-checking or observer code to the initially trivial
getters/setters as the need arises.
Yeah, I think that's a good guideline. There are definitely some
accessors I'd like to encapsulate a little better.
-Ken
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
| 
