On Feb 29, 2004, at 10:28 AM, Ken Williams wrote:
On Tuesday, February 24, 2004, at 03:53 PM, Martyn Peck wrote:
One of the problems I've run into is that whenever a script uses
Module::Build (using new/resume/current), it always assumes it's in
the package base directory. [...] ... but a little educated guessing
wouldn't hurt either.
I think in this case educated guessing *will* hurt. Its configuration
information should either be exactly where it expects it to be, or it
should be explicitly told an alternate location. It would be pretty
terrible if it loaded the wrong set of config information and started
using it, you could create a big mess that way.
Fair enough. But in that case ....
[...] ... and has $build->{properties}{base_dir} properly set, it
still looks in the current directory for the configuration directory
when trying to load the notes or prereqs file. [...]
I tried to do this myself once, actually. The only reason I didn't
finish was that it was getting awfully messy, but in principle I think
it's a good idea. We could try again.
...isn't that exactly what your doing here? Anyway, this does sound
like something that needs to be done.
Another problem I've had is that there's no clean way to separate out
the arguments specifically needed by Apache::Test in other scripts. I
don't want to have to parse $build->{args} in every single test file,
but I don't see any place where I can easily do this in one pass. I
ended up rewriting the merge_args method to separate out the
Apache::Test args and put them in a notes tag. And that won't work
anymore when I also start using DBIx::Test.
I'm not sure I understand this point very well, could you give me a
concrete example?
Sure. When I was subclassing MB to use Apache::Test, I had to pass some
command line arguments from Build.pl to the Apache::TestRun module in
the t/TEST script. Normally I would just lookup a $build->{args} and
use that. Unfortunately, Apache::TestRun as an annoying little
die_on_invalid_args() method. So somehow I had to filter out the args
that only apply to Apache::Test. I ended up overriding the merge_args
method, where I simply copied most of the existing code, and slipped in
extra bits that put the Apache::Test specific args in a notes entry.
Now, when I'm copying that much code, it usually means one of two
things: Either I'm using the code in a way that it was never intended
to be used, or the code lacks allot of flexibility.
[...]
I'd recommend that in your M::B subclass you get configuration
information, store it in notes(), then do your setup/teardown in an
overridden ACTION_test() method. If the regression test scripts
themselves need to get at configuration information, they can use
current()->notes() to get it. Does this sound workable?
Sorry, I obviously didn't explain this well enough (and I'm not sure
I'll do any better now). Lets say that I have a module MB::Foo that
subclasses MB, and overrides ACTION_test() so it calls a setup_foo()
method. I also make a module MB::Bar that's also a subclass of MB, and
overrides ACTION_test() to call a setup_bar() method. So far, this is
simple, easy and straight forward. But suppose I'm making a
distribution that needs both MB::Foo and MB::Bar. How do I set it up to
make sure both setup_foo() and setup_bar() are always called.
Anyway, thanks for the reply.
Marty
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
|
