On Jun 21, 2004, at 6:12 PM, David Wheeler wrote:
Here's a new subclass for Module::Build, Apache::TestMB, which allows modules that use Module::Build to run tests using Apache::Test.
Let me make a few comments on my "XXX" comments in the source code, and aske a couple of questions:
* In ACTION_test_clean() and ACTION_run_tests(), I'd love to be able to dump the dependence on t/TEST. My thought was to make calling generate_script() optional. It would only be called by module developers who had special needs, and had created t/TEST.PL to handle them. If this method was never called (and therefore apache_test_script had no value), then ACTION_test_clean() and ACTION_run_tests() could carry out their actions directly.
This is Perl, after all, so theoretically, Build doing the work is the same as t/TEST doing the work. I tried to implement this, but it looked like there were too many dependencies on the presence of t/TEST in Apache::TestRun::run. It also takes a whole slew of options. These issues would have to be addressed before we could make t/TEST optional. Ideally, ACTION_test() would just look like this:
sub ACTION_run_tests { my $self = shift; $self->depends_on('code'); $self->depends_on('test_clean'); my @files = $ENV{TEST_FILES} ? ($ENV{TEST_FILES}) : (); if (my $script = $self->apache_test_script) { # Execute the test script. return $self->do_system($self->perl, $self->_bliblib, $self->localize_file_path($script), '-bugreport', ('-verbose=' . ($self->verbose || 0)), @files); }
# Just run things directly. $self->depends_on('start_httpd'); $self->SUPER::ACTION_test(@_); $self->depends_on('kill_httpd'); $self->depends_on('test_clean'); }
Stas, is it possible to implement the necessary methods to do what t/TEST normally does from within Module::Build?
Absolutely. It's really just:
MyTest->new->run(@ARGV);
where MyTest is a subclass of Apache::TestRunPerl
Though you will need to figure out how to pass the options, which is already not trivial at all, since there are quite a few ways to feed them in at different phases. May be you should use a wrapper around t/TEST which works just the same.
* I wasn't sure how the TEST_FILES environment variable was supposed to work. So I'm just passing it to the call to t/TEST if it exists. Stas, is this the correct thing to do?
I think yes, but why not keep it an env var?
* This isn't commented in the code I sent you, but I'll note it: I didn't implement "cmodules" or "cmodules_clean" actions. They appear simple, but they seem to depend on `make` rather than Module::Build. Stas, are these just that simple? Should I expect that there'd be a Makefile in the cmodules directory? Or might it be Module::Build-based? I guess the real question is, where does that Makefile come from?
I believe it's autogenerated, I didn't write that code, so you can look just as well :) You can use libapreq-2's source from CPAN to see how c-modules work.
I've skimmed the source, it looks good David, but please use indentation of 4 everywhere.
Also how the following code is supposed to work?
my $infile = '$script.PL';
if (-f $infile) {Also you can use shortcuts from Apache::TestTrace to do logging.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
