You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by David Wheeler <da...@kineticode.com> on 2004/06/22 03:12:56 UTC
Apache::TestMB
Hi All,
Here's a new subclass for Module::Build, Apache::TestMB, which allows
modules that use Module::Build to run tests using Apache::Test. My
assumption is that it would be distributed with Apache::Test; therefore
its use is something like this:
use Module::Build;
my $build_pkg = eval { require Apache::TestMB }
? 'Apache::TestMB' : 'Module::Build';
my $build = $build_pkg->new(
module_name => 'My::Module',
)->create_build_script;
Let me know what you think!
Regards,
David
PS: Holler if this doesn't come through and I'll resend it gzip'ed.
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 23, 2004, at 9:19 AM, Stas Bekman wrote:
> As I mentioned I don't know how to test it, so if you think it's good,
> then nothing stops us from doing that. We ought to post a release
> candidate and 24 later go on CPAN.
That works for me. As I said, I'll release
MasonX::Interp::WithCallbacks to use it as soon as it's released to
CPAN. There will no doubt soon be others, too:
http://www.justatheory.com/computers/programming/perl/mod_perl/
apache_testmb.html
Regards,
David
Re: Apache::TestMB
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
David Wheeler wrote:
> On Jun 23, 2004, at 1:26 PM, Geoffrey Young wrote:
>
>> sure, I'll try to wrap up a candidate tomorrow.
>
>
> Sweet, thanks!
ok, I did this a few hours ago, but the announcement email hasn't made it
through.
testing...
--Geoff
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 23, 2004, at 1:26 PM, Geoffrey Young wrote:
> sure, I'll try to wrap up a candidate tomorrow.
Sweet, thanks!
David
Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
>>Geoff, if you have no objections, can you handle this release? I'm on
>>the road and not the most suitable person to do the release at the moment.
>
>
> sure, I'll try to wrap up a candidate tomorrow.
Thanks Geoff!
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> David Wheeler wrote:
>
>> On Jun 23, 2004, at 9:02 AM, Stas Bekman wrote:
>>
>>> Now committed with a few minor tweaks, please test it since I don't
>>> know how to test it. Thanks David.
>>
>>
>>
>> Cool, thanks. What do you need to be able to feel comfortable/ready to
>> release it?
>
>
> As I mentioned I don't know how to test it, so if you think it's good,
> then nothing stops us from doing that. We ought to post a release
> candidate and 24 later go on CPAN.
>
> Geoff, if you have no objections, can you handle this release? I'm on
> the road and not the most suitable person to do the release at the moment.
sure, I'll try to wrap up a candidate tomorrow.
--Geoff
Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Jun 23, 2004, at 9:02 AM, Stas Bekman wrote:
>
>> Now committed with a few minor tweaks, please test it since I don't
>> know how to test it. Thanks David.
>
>
> Cool, thanks. What do you need to be able to feel comfortable/ready to
> release it?
As I mentioned I don't know how to test it, so if you think it's good, then
nothing stops us from doing that. We ought to post a release candidate and 24
later go on CPAN.
Geoff, if you have no objections, can you handle this release? I'm on the road
and not the most suitable person to do the release at the moment.
p.s. perhaps someone can approve my posts to module-build-general, I keep on
getting those moderation awaiting notices or drop that list from CC. Thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 23, 2004, at 9:02 AM, Stas Bekman wrote:
> Now committed with a few minor tweaks, please test it since I don't
> know how to test it. Thanks David.
Cool, thanks. What do you need to be able to feel comfortable/ready to
release it?
> It's a well kept secret :) existing committers need to vote first,
> I'll keep you posted as I get more information.
Thanks.
Regards,
David
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 23, 2004, at 10:02 AM, Stas Bekman wrote:
> Now committed with a few minor tweaks, please test it since I don't
> know how to test it. Thanks David.
Here's a quick documentation patch, essentially, for the unimplemented
cmodules actions:
--- lib/Apache/TestMB.pm.~1.1.~ Wed Jun 23 09:51:15 2004
+++ lib/Apache/TestMB.pm Wed Jun 23 17:26:10 2004
@@ -82,8 +82,9 @@
# XXX TBD.
my $start_dir = $self->cwd;
chdir $self->localize_file_path('c-modules');
- # XXX How do we get the right make?
- $self->do_system('make', $action);
+ # XXX How do we get Build.PL to be generated instead of Makefile?
+ # Subclass Apache::TestConfigC, perhaps?
+ $self->do_system('Build.PL', $action);
chdir $start_dir;
}
Regards,
David
Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
Now committed with a few minor tweaks, please test it since I don't know how
to test it. Thanks David.
>> Moreover, I think it's time to give you commit access to A-T if you
>> wish to. Do you have an account at apache.org?
>
>
> I don't. How do I get one? A quick look around www.apache.org/dev/
> doesn't reveal much...
It's a well kept secret :) existing committers need to vote first, I'll keep
you posted as I get more information.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 22, 2004, at 3:34 PM, David Wheeler wrote:
>> I doubt so. Just make it die with the appropriate message, so that if
>> someone needs it they will know that it'll be added in the future.
>
> Okay, done.
Uh, and here it is.
Regards,
David
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 22, 2004, at 3:15 PM, Stas Bekman wrote:
> Yes, but it won't work for modules not using MB, so it's better to
> have something common. We can always change things later if we find it
> beneficial. Nothing is cast in stone as long as it doesn't add a huge
> overhead for the user's learning curve.
My sentiments exactly.
> I doubt so. Just make it die with the appropriate message, so that if
> someone needs it they will know that it'll be added in the future.
Okay, done.
> generate_script does it for you too.
TestMM::generate_script doesn't, but TestRun->generate_script() does.
I've been using the latter in my Makefile.PL.
> It doesn't matter for now. I was just mentioning a feature that you
> may find useful.
Oh, okay. Thanks. :-)
> It'd be nice to actually try your patch in action with some module
> that uses MB before committing it. Other than that +1 and thank you,
> David.
I've tried it with MasonX::Interp::WithCallbacks, which I will release
with the Build.PL as soon as Apache::Test is released with
Apache::TestMB.
> Moreover, I think it's time to give you commit access to A-T if you
> wish to. Do you have an account at apache.org?
I don't. How do I get one? A quick look around www.apache.org/dev/
doesn't reveal much...
Regards,
David
Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
Ken Williams wrote:
>
> On Jun 22, 2004, at 5:15 PM, Stas Bekman wrote:
>
>> David Wheeler wrote:
>>
>>> I figured. I like my style, too (mainly just cperl-mode style). ;-)
>>
>>
>> pretty much the same here, cperl-mode too :)
>
>
> For HTML::Mason we found it helpful to add the following as the first
> line of source files:
>
> # -*- cperl-indent-level: 4; cperl-continued-brace-offset: -4;
> cperl-continued-statement-offset: 4 -*-
If every A-T developer was using emacs, it'd make sense. Since that's not the
case, I think we don't want to start clutter the files with special modes
embedded for each editor used by developers.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Posted by Ken Williams <ke...@mathforum.org>.
On Jun 22, 2004, at 5:15 PM, Stas Bekman wrote:
> David Wheeler wrote:
>> I figured. I like my style, too (mainly just cperl-mode style). ;-)
>
> pretty much the same here, cperl-mode too :)
For HTML::Mason we found it helpful to add the following as the first
line of source files:
# -*- cperl-indent-level: 4; cperl-continued-brace-offset: -4;
cperl-continued-statement-offset: 4 -*-
-Ken
Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote:
>
>> It may be a fairly complex logic to add, though you could write
>> wrappers that simply push things into @ARGV, emulating the command line.
>>
>> Though I'd rather have one way to do things. It's already a
>> non-trivial thing with all the multiple options. If we have to explain
>> to the user in trouble with the test suite more than one way to help
>> us show their problems, it makes things even more complex and
>> confusing. So if you can keep t/TEST as it is I think it'll be a good
>> thing. Feel free to convince me otherwise. Admittedly I have never
>> used MB, so I may miss some things.
>
>
> I'll leave it; I don't have the tuits to change it. I'm just happy to
> have something that works with Module::Build. My only thought was that
> t/TEST seemed like a hack to get something Perlish to work in a C<make>
> environment. And since Module::Build is a Perl environment, that hack is
> no longer necessary. But I recognize that there has been a lot built up
> around that hack, so it's much simpler to follow the 80/20 rule and get
> it done the way it is.
Yes, but it won't work for modules not using MB, so it's better to have
something common. We can always change things later if we find it beneficial.
Nothing is cast in stone as long as it doesn't add a huge overhead for the
user's learning curve.
>> Somewhere around that code that deals with cmodules:
>>
>> grep -Ir cmodules Apache-Test/lib/Apache/
>
>
> Yes, Randy has been pointing it out. But does TestMB need this support
> in an initial release? Seems like those who depend on the Makefile will
> keep using TestMM for a while.
I doubt so. Just make it die with the appropriate message, so that if someone
needs it they will know that it'll be added in the future.
>> No, no, it's fine. But don't worry, once the patch is finished I'll go
>> over it to make it consistent with the rest of the code. Most of
>> things are just perfect.
>
>
> I figured. I like my style, too (mainly just cperl-mode style). ;-)
pretty much the same here, cperl-mode too :)
>>>> I meant the fact that '$script.PL' doesn't interpolate $script.
>>>
>>> Oh, duh. Fixed.
>>
>>
>> I guess that part of the code is not really tested :)
>
>
> I never, *ever,* create my own t/TEST.PL, so no, it isn't.
generate_script does it for you too.
>> Instead of:
>>
>> print "Bar tar car\n";
>>
>> use Apache::TestTrace;
>>
>> debug "Bar tar car\n";
>>
>> Now replace debug with whatever level you want this message to be
>> printed at. By default the trace level is 'info', so unless user
>> changes the default, traces:
>>
>> emerg alert crit error warning notice info
>>
>> will always log things, whereas debug() won't. So for example in your
>> case you could use the notice() func. Apache::TestTrace really mimicks
>> the LogLevel from Apache.
>
> Are you suggesting that it be used inside Apache::TestMB? There's only
> one print statement, in generate_script(), and there I followed the
> approach of Module::Build, even though TestMM used info.
It doesn't matter for now. I was just mentioning a feature that you may find
useful.
> So, what more do you need before committing this puppy? I'm ready to
> take advantage of it with my module and upload that module to CPAN! ;-)
It'd be nice to actually try your patch in action with some module that uses
MB before committing it. Other than that +1 and thank you, David.
Moreover, I think it's time to give you commit access to A-T if you wish to.
Do you have an account at apache.org?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote:
> It may be a fairly complex logic to add, though you could write
> wrappers that simply push things into @ARGV, emulating the command
> line.
>
> Though I'd rather have one way to do things. It's already a
> non-trivial thing with all the multiple options. If we have to explain
> to the user in trouble with the test suite more than one way to help
> us show their problems, it makes things even more complex and
> confusing. So if you can keep t/TEST as it is I think it'll be a good
> thing. Feel free to convince me otherwise. Admittedly I have never
> used MB, so I may miss some things.
I'll leave it; I don't have the tuits to change it. I'm just happy to
have something that works with Module::Build. My only thought was that
t/TEST seemed like a hack to get something Perlish to work in a C<make>
environment. And since Module::Build is a Perl environment, that hack
is no longer necessary. But I recognize that there has been a lot built
up around that hack, so it's much simpler to follow the 80/20 rule and
get it done the way it is.
> Somewhere around that code that deals with cmodules:
>
> grep -Ir cmodules Apache-Test/lib/Apache/
Yes, Randy has been pointing it out. But does TestMB need this support
in an initial release? Seems like those who depend on the Makefile will
keep using TestMM for a while.
> No, no, it's fine. But don't worry, once the patch is finished I'll go
> over it to make it consistent with the rest of the code. Most of
> things are just perfect.
I figured. I like my style, too (mainly just cperl-mode style). ;-)
>>> I meant the fact that '$script.PL' doesn't interpolate $script.
>> Oh, duh. Fixed.
>
> I guess that part of the code is not really tested :)
I never, *ever,* create my own t/TEST.PL, so no, it isn't.
> Instead of:
>
> print "Bar tar car\n";
>
> use Apache::TestTrace;
>
> debug "Bar tar car\n";
>
> Now replace debug with whatever level you want this message to be
> printed at. By default the trace level is 'info', so unless user
> changes the default, traces:
>
> emerg alert crit error warning notice info
>
> will always log things, whereas debug() won't. So for example in your
> case you could use the notice() func. Apache::TestTrace really mimicks
> the LogLevel from Apache.
Are you suggesting that it be used inside Apache::TestMB? There's only
one print statement, in generate_script(), and there I followed the
approach of Module::Build, even though TestMM used info.
So, what more do you need before committing this puppy? I'm ready to
take advantage of it with my module and upload that module to CPAN! ;-)
Regards,
David
Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
>> How are you going to avoid that? I mean your users need to be able to
>> run certain features of Apache-Test, which are beyond 'make test'. May
>> be you want to always create t/TEST, but run 'make test' without
>> invoking t/TEST?
>
>
> I meant that I wanted to avoid dealing with it. ;-) The current approach
> works, but if I get rid of t/TEST, I would have to deal with it. The
> only other approach would be if this stuff was abstracted into a
> function or method in Apache::TestRun. Then I could just call it with
> the appropriate arguments.
It may be a fairly complex logic to add, though you could write wrappers that
simply push things into @ARGV, emulating the command line.
Though I'd rather have one way to do things. It's already a non-trivial thing
with all the multiple options. If we have to explain to the user in trouble
with the test suite more than one way to help us show their problems, it makes
things even more complex and confusing. So if you can keep t/TEST as it is I
think it'll be a good thing. Feel free to convince me otherwise. Admittedly I
have never used MB, so I may miss some things.
>> there is no C, there is perl that creates the necessary build
>> environment.
>
> Oh, sorry. Where do I find it?
Somewhere around that code that deals with cmodules:
grep -Ir cmodules Apache-Test/lib/Apache/
>> Yes please, we use 4 everywhere.
>
>
> Ick. Done. I only noticed two spaces in one place in generate_script().
> Unless you want lines following an opening paren (as in the calls to
> do_system()) to be indented only 4 spaces, rather than lined up with the
> previous line?
No, no, it's fine. But don't worry, once the patch is finished I'll go over it
to make it consistent with the rest of the code. Most of things are just perfect.
>> I meant the fact that '$script.PL' doesn't interpolate $script.
>
>
> Oh, duh. Fixed.
I guess that part of the code is not really tested :)
>>>> Also you can use shortcuts from Apache::TestTrace to do logging.
>>>
>>> Um, I have no idea what you're talking about here. Sorry.
>>
>>
>> use Apache::TestTrace;
>>
>> debug "foo";
>>
>> error "bar";
>>
>> etc...
>>
>> The tracelevel will automatically enable and disable various trace
>> levels. See Apache::TestTrace for more info.
>
>
> Um, okay, but what needs to change in TestMB.pm to address this? Is
> there something missing? I didn't notice anything about this in TestMM.pm.
Instead of:
print "Bar tar car\n";
use Apache::TestTrace;
debug "Bar tar car\n";
Now replace debug with whatever level you want this message to be printed at.
By default the trace level is 'info', so unless user changes the default, traces:
emerg alert crit error warning notice info
will always log things, whereas debug() won't. So for example in your case you
could use the notice() func. Apache::TestTrace really mimicks the LogLevel
from Apache.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 22, 2004, at 11:05 AM, Stas Bekman wrote:
> ah, yes, it tries to figure out where it is and move out of t/, as per
> your request earlier. Feel free to suggest a way to work it out. That
> particular code could be made into a subclassable method, which your
> subclass could implement differently.
Fair enough.
> How are you going to avoid that? I mean your users need to be able to
> run certain features of Apache-Test, which are beyond 'make test'. May
> be you want to always create t/TEST, but run 'make test' without
> invoking t/TEST?
I meant that I wanted to avoid dealing with it. ;-) The current
approach works, but if I get rid of t/TEST, I would have to deal with
it. The only other approach would be if this stuff was abstracted into
a function or method in Apache::TestRun. Then I could just call it with
the appropriate arguments.
> Creo que si, i.e. yes :)
Done, thanks.
> there is no C, there is perl that creates the necessary build
> environment.
Oh, sorry. Where do I find it?
> Yes please, we use 4 everywhere.
Ick. Done. I only noticed two spaces in one place in generate_script().
Unless you want lines following an opening paren (as in the calls to
do_system()) to be indented only 4 spaces, rather than lined up with
the previous line?
> I meant the fact that '$script.PL' doesn't interpolate $script.
Oh, duh. Fixed.
>>> Also you can use shortcuts from Apache::TestTrace to do logging.
>> Um, I have no idea what you're talking about here. Sorry.
>
> use Apache::TestTrace;
>
> debug "foo";
>
> error "bar";
>
> etc...
>
> The tracelevel will automatically enable and disable various trace
> levels. See Apache::TestTrace for more info.
Um, okay, but what needs to change in TestMB.pm to address this? Is
there something missing? I didn't notice anything about this in
TestMM.pm.
Regards,
David
Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Jun 22, 2004, at 10:33 AM, Stas Bekman wrote:
>
>> Absolutely. It's really just:
>>
>> MyTest->new->run(@ARGV);
>>
>> where MyTest is a subclass of Apache::TestRunPerl
>
>
> I tried that, but it didn't work. I'm not sure why. The first problem
> was this code:
>
> $0 = File::Spec->rel2abs($0);
> if (-e $0) {
> my $top = dirname dirname $0;
> chdir $top if $top and -d $top;
> }
>
> Which moved things out of the module root, since Build.PL isn't in t/. I
> got 'round that by doing C<local $0 = ''>, but then nothing else
> happened. Odd.
ah, yes, it tries to figure out where it is and move out of t/, as per your
request earlier. Feel free to suggest a way to work it out. That particular
code could be made into a subclassable method, which your subclass could
implement differently.
>> 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.
>
>
> Yes, that's the other thing I wanted to avoid.
How are you going to avoid that? I mean your users need to be able to run
certain features of Apache-Test, which are beyond 'make test'. May be you want
to always create t/TEST, but run 'make test' without invoking t/TEST?
>>> * 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?
>
>
> It is an environment variable. If, however, you mean that t/TEST spots
> the environment variable and does the right thing, then cool, I'll
> simply take out out of TestMB.
Creo que si, i.e. yes :)
>> 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.
>
>
> Pass. I don't really do C. I put in some stubs for it, though.
there is no C, there is perl that creates the necessary build environment.
>> I've skimmed the source, it looks good David, but please use
>> indentation of 4 everywhere.
>
>
> I did; only lines that continue from a previous line use two spaces. If
> you want four there (confusing, IMO), I can change it.
Yes please, we use 4 everywhere.
>> Also how the following code is supposed to work?
>>
>> my $infile = '$script.PL';
>> if (-f $infile) {
>
>
> It will use t/TEST.PL to generate t/TEST if t/TEST.PL exists. Otherwise,
> it generates t/TEST like TestConfig::generate_script(). does.
I meant the fact that '$script.PL' doesn't interpolate $script.
>> Also you can use shortcuts from Apache::TestTrace to do logging.
>
>
> Um, I have no idea what you're talking about here. Sorry.
use Apache::TestTrace;
debug "foo";
error "bar";
etc...
The tracelevel will automatically enable and disable various trace levels. See
Apache::TestTrace for more info.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 22, 2004, at 6:23 AM, Ken Williams wrote:
> ./Build help should work already. ./Build help $newaction should work
> automatically if you add documentation for each action - it searches
> for docs using the regex /^=item\s+\Q$action\E\b/ .
Ah, I had "=item C<action>". I'll remove the C<>.
Thanks,
David
Re: Apache::TestMB
Posted by Ken Williams <ke...@mathforum.org>.
On Jun 22, 2004, at 12:18 AM, David Wheeler wrote:
>
> * Ken, how do I add code so that ./Build help lists the new actions,
> and ./Build help $new_action prints out some documentation for the
> action?
>
./Build help should work already. ./Build help $newaction should work
automatically if you add documentation for each action - it searches
for docs using the regex /^=item\s+\Q$action\E\b/ .
-Ken
Re: [Module::Build] Re: Apache::TestMB
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 22 Jun 2004, David Wheeler wrote:
>
>
>>On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote:
>>
>>
>>>Right now the Makefile is generated by methods within
>>>Apache/TestConfigC.pm, which generally consists of calling
>>>the apxs utility to compile the module (as well as
>>>implementing a 'clean' target). In principle I think this
>>>could be done via Module::Build with an appropriate
>>>Build.PL and the corresponding changes within
>>>Apache/TestConfigC.pm to call it.
>>
>>Okay. I've put in some placeholder methods for this;
>>Randy, can you add the necessary code?
>
>
> Sure, it should be relatively straightforward ... But I'd
> like to get, especially, Stas' opinion on this - adding this
> in will necessarily introduce a few branches in the
> Apache/TestConfigC.pm code related to, first of all, whether
> to write a Makefile.PL or a Build.PL (and the ensuing
> different syntax), and then secondly, how to use them.
Let's deal with that when the need arises.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Module::Build] Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 22, 2004, at 12:19 PM, Randy Kobes wrote:
> Sure, it should be relatively straightforward ... But I'd
> like to get, especially, Stas' opinion on this - adding this
> in will necessarily introduce a few branches in the
> Apache/TestConfigC.pm code related to, first of all, whether
> to write a Makefile.PL or a Build.PL (and the ensuing
> different syntax), and then secondly, how to use them.
Actually, it seems like we could subclass it, no? When does it get
called, and how?
Regards,
David
Re: [Module::Build] Re: Apache::TestMB
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 22 Jun 2004, David Wheeler wrote:
> On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote:
>
> > Right now the Makefile is generated by methods within
> > Apache/TestConfigC.pm, which generally consists of calling
> > the apxs utility to compile the module (as well as
> > implementing a 'clean' target). In principle I think this
> > could be done via Module::Build with an appropriate
> > Build.PL and the corresponding changes within
> > Apache/TestConfigC.pm to call it.
>
> Okay. I've put in some placeholder methods for this;
> Randy, can you add the necessary code?
Sure, it should be relatively straightforward ... But I'd
like to get, especially, Stas' opinion on this - adding this
in will necessarily introduce a few branches in the
Apache/TestConfigC.pm code related to, first of all, whether
to write a Makefile.PL or a Build.PL (and the ensuing
different syntax), and then secondly, how to use them.
--
best regards,
randy
Re: [Module::Build] Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote:
> Right now the Makefile is generated by methods within
> Apache/TestConfigC.pm, which generally consists of calling
> the apxs utility to compile the module (as well as
> implementing a 'clean' target). In principle I think this
> could be done via Module::Build with an appropriate
> Build.PL and the corresponding changes within
> Apache/TestConfigC.pm to call it.
Okay. I've put in some placeholder methods for this; Randy, can you add
the necessary code?
Regards,
David
Re: Apache::TestMB
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 21 Jun 2004, David Wheeler wrote:
[ ... ]
> * 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?
Right now the Makefile is generated by methods within
Apache/TestConfigC.pm, which generally consists of calling
the apxs utility to compile the module (as well as
implementing a 'clean' target). In principle I think this
could be done via Module::Build with an appropriate
Build.PL and the corresponding changes within
Apache/TestConfigC.pm to call it.
--
best regards,
randy kobes
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
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?
* 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?
* 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?
* Ken, how do I add code so that ./Build help lists the new actions,
and ./Build help $new_action prints out some documentation for the
action?
TIA for the feedback, Guys!
Regards,
David
Re: Apache::TestMB
Posted by David Wheeler <da...@kineticode.com>.
On Jun 21, 2004, at 8:29 PM, Ken Williams wrote:
> I see - so the author would design their tests so they could be run
> either with or without a live server? I'm guessing many authors would
> want to require a live server, and thus rely on Apache::TestMB.
Most module authors design their tests to rely on the presence or
absences of Apache::Test already, AFAIK. t/08apache.t in
MasonX::Interp::WithCallbacks, for example, looks like this:
BEGIN {
plan skip_all => 'Testing of apache_req requires Apache::Test'
unless eval {require Apache::Test};
plan skip_all => 'Test of apache_req requires mod_perl'
unless Apache::Test::have_module('mod_perl.c');
require Apache::TestRequest;
Apache::TestRequest->import(qw(GET POST));
plan tests => 178;
}
Anyway, this gives them the option; they could always put Apache::Test
in build_requires and then expect it to be there, I guess.
Regards,
David
Re: Apache::TestMB
Posted by Ken Williams <ke...@mathforum.org>.
On Jun 21, 2004, at 8:12 PM, David Wheeler wrote:
> Hi All,
>
> Here's a new subclass for Module::Build, Apache::TestMB, which allows
> modules that use Module::Build to run tests using Apache::Test. My
> assumption is that it would be distributed with Apache::Test;
> therefore its use is something like this:
>
> use Module::Build;
>
> my $build_pkg = eval { require Apache::TestMB }
> ? 'Apache::TestMB' : 'Module::Build';
I see - so the author would design their tests so they could be run
either with or without a live server? I'm guessing many authors would
want to require a live server, and thus rely on Apache::TestMB.
-Ken