Re: Apache::TestMB error
On Sep 10, 2004, at 3:00 PM, William McKee wrote: I'm getting an error when trying to use Stas' template[1] with your module. Basically, the filter_args() method is generating an error. I am calling it like this: Apache::TestMB::filter_args(); You don't need to do that. Apache::TestMB does it for you. My build seems to work fine with this method commented out. However, I'm wondering if this is an oversight in the A::TestMB module or an incompatibility. No, not an oversight. I just made its interface simpler and more OO than Apache::TestMM's. [1] http://perl.apache.org/docs/general/testing/ testing.html#Basic_Testing_Environment (you'll need to scroll down a bit til you get to the Makefile.PL example) Scroll down a bit more to see the Build.PL example I added. Regards, David
Re: Apache::TestMB error
On Fri, Sep 10, 2004 at 04:07:35PM -0700, David Wheeler wrote: I'm getting an error when trying to use Stas' template[1] with your module. Basically, the filter_args() method is generating an error. I am calling it like this: Apache::TestMB::filter_args(); You don't need to do that. Apache::TestMB does it for you. Nice. My build seems to work fine with this method commented out. However, I'm wondering if this is an oversight in the A::TestMB module or an incompatibility. No, not an oversight. I just made its interface simpler and more OO than Apache::TestMM's. I'm liking Module::Build more and more ;). Scroll down a bit more to see the Build.PL example I added. Oops, I hadn't realized that you updated that page after you released Apache::TestMB. Thanks for your work on integrating M::B with Apache::Test. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::TestMB error
On Sep 11, 2004, at 10:19 AM, William McKee wrote: I'm liking Module::Build more and more ;). Me, too. Scroll down a bit more to see the Build.PL example I added. Oops, I hadn't realized that you updated that page after you released Apache::TestMB. Thanks for your work on integrating M::B with Apache::Test. Sure, turned out to be pretty easy, I'm happy to say. Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: Apache::TestMB returns 1
David Wheeler wrote:
On Jul 5, 2004, at 11:09 AM, David Wheeler wrote:
Can't locate object method generate_script via package
Apache::TestMB at Build.PL line 62.
Oh, sorry, it's generate_test_script().
And I have no idea why it is, since it's generate_script in the other
A::T modules, and I documented it that way. Apologies. This patch will
fix it (Stas, we should commit this for the next release):
-- TestMB.pm.~1.2.~Fri Jun 25 18:55:53 2004
+++ TestMB.pmMon Jul 5 11:10:36 2004
@@ -15,7 +15,7 @@
my $self = $pkg-SUPER::new(@_);
$self-{properties}{apache_test_args} = $vars;
$self-{properties}{apache_test_script} ||= 't/TEST';
-$self-generate_test_script;
+$self-generate_script;
return $self;
}
@@ -92,7 +92,7 @@
sub ACTION_cmodules_clean { shift-_cmodues('clean') }
# XXX I'd love to make this optional.
-sub generate_test_script {
+sub generate_script {
my $self = shift;
# If a file name has been passed in, use it. Otherwise, use the
Committed, should there be a log in Changes?
--
__
Stas BekmanJAm_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
Re: Apache::TestMB returns 1
On Jul 6, 2004, at 12:56 AM, Stas Bekman wrote: Committed, should there be a log in Changes? Yep, thanks. David
Re: Apache::TestMB returns 1
On Fri, Jul 02, 2004 at 09:51:32AM -0700, David Wheeler wrote:
Oh, quite right. My fault. This patch fixes the docs:
--- TestMB.pm.~1.2.~ Fri Jun 25 18:55:53 2004
+++ TestMB.pm Fri Jul 2 09:49:40 2004
@@ -180,7 +180,7 @@
my $build_pkg = eval { require Apache::TestMB }
? 'Apache::TestMB' : 'Module::Build';
- my $build = $build_pkg-new(
+ $build_pkg-new(
module_name = 'My::Module',
)-create_build_script;
Actually I'd prefer the following format:
my $build = $build_pkg-new (...);
$build-create_build_script;
The reason is that this shows how to work with a build object. This is
necessary if you want to use methods such as generate_script.
I don't know what's in the SMOKE script, since I never used it.
I copied it verbatim from the testing page[1] on the mod_perl website.
It's a handy utility!
You can use Apache::TestMB-generate_script, however; will that work?
When I try running generate_smoke, I get the following output:
Can't locate object method generate_script via package Apache::TestMB at
Build.PL line 62.
It should do pretty much the same things as
Apache::TestMM::generate_smoke().
Should that be Apache::TestMM::generate_script()?
Regards,
William
[1]
http://perl.apache.org/docs/general/testing/testing.html#C_Apache__TestSmoke__Solution
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Apache::TestMB returns 1
On Jul 5, 2004, at 9:01 AM, William McKee wrote: Actually I'd prefer the following format: my $build = $build_pkg-new (...); $build-create_build_script; The reason is that this shows how to work with a build object. This is necessary if you want to use methods such as generate_script. Yeah, I was just following the example in the synopsis of the Module::Build docs. Either is fine with me, too. What do others prefer? You can use Apache::TestMB-generate_script, however; will that work? When I try running generate_smoke, I get the following output: Can't locate object method generate_script via package Apache::TestMB at Build.PL line 62. Oh, sorry, it's generate_test_script(). It should do pretty much the same things as Apache::TestMM::generate_smoke(). Should that be Apache::TestMM::generate_script()? Yes, duh. Sorry. David
Re: Apache::TestMB returns 1
On Mon, Jul 05, 2004 at 11:09:47AM -0700, David Wheeler wrote: When I try running generate_smoke, I get the following output: Now I'm doing it! That should have been generate_script. Oh, sorry, it's generate_test_script(). OK, that worked. Why is it named differently from the format used by Apache::TestMM? Nevermind, I see your follow-up message. That works for me! Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::TestMB returns 1
On Jul 5, 2004, at 11:53 AM, William McKee wrote: OK, that worked. Why is it named differently from the format used by Apache::TestMM? Nevermind, I see your follow-up message. That works for me! Probably do to some overly-aggressive find and replace or something. Sorry about that! David
Re: Apache::TestMB returns 1
On Jul 2, 2004, at 9:19 AM, William McKee wrote: Thanks for your efforts in adding support Glad it works for you! This reminds me: --- Test.pm.~1.84.~ Fri Jun 25 18:55:53 2004 +++ Test.pm Fri Jul 2 09:27:18 2004 @@ -807,7 +807,8 @@ exports a number of useful functions for sending request to the Apache test server. You can then test the results of those requests. -Use LApache::TestMM|Apache::TestMM in your FMakefile.PL to set up your +Use LApache::TestMM|Apache::TestMM in your FMakefile.PL or +LApache::TestMB::Apache::TestMB in your FBuild.PL to set up your distribution for testing. =head1 AUTHOR Regards, David
Re: Apache::TestMB returns 1
On Jul 2, 2004, at 9:34 AM, William McKee wrote:
Hi all,
Sorry about that false start. Lemme try this again! As I was saying,
David, thanks for adding support for Module::Build. I'm trying to
replace one of my existing projects using the Apache::TestMB module. It
works fine unless I try to do something with the return value from the
examples:
my $build = $build_pkg-new(
module_name = 'My::Module',
dist_version = '0.1.0',
)-create_build_script;
I was getting 1 back in $build. In preparing this email, I realized
that
the results of new() are immediately calling create_build_script()
which
is returning 1.
Oh, quite right. My fault. This patch fixes the docs:
--- TestMB.pm.~1.2.~Fri Jun 25 18:55:53 2004
+++ TestMB.pm Fri Jul 2 09:49:40 2004
@@ -180,7 +180,7 @@
my $build_pkg = eval { require Apache::TestMB }
? 'Apache::TestMB' : 'Module::Build';
- my $build = $build_pkg-new(
+ $build_pkg-new(
module_name = 'My::Module',
)-create_build_script;
Now, that I have that issue figured out, I'm trying to use the build
object to generate a SMOKE script. The TEST script seems to be
automatically built. The generate_script() method that I was using with
A::TestMM is not available. Is there another way I should be generating
this script?
I don't know what's in the SMOKE script, since I never used it. You can
use Apache::TestMB-generate_script, however; will that work? It should
do pretty much the same things as Apache::TestMM::generate_smoke().
Regards,
David
Re: Apache::TestMB
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
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.pmWed 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
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: [Module::Build] Re: Apache::TestMB
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 BekmanJAm_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
Re: Apache::TestMB
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
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 BekmanJAm_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
Re: Apache::TestMB
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 BekmanJAm_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
Re: Apache::TestMB
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 BekmanJAm_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
Re: Apache::TestMB
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
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
Re: Apache::TestMB
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
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
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
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 Caction. I'll remove the C. Thanks, David
Re: [Module::Build] Re: Apache::TestMB
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
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 Clocal $0 = '', but then nothing else
happened. Odd.
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.
May be you should use a wrapper around t/TEST which works just the
same.
That's the way it works now.
* 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.
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.
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.
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.
Also you can use shortcuts from Apache::TestTrace to do logging.
Um, I have no idea what you're talking about here. Sorry.
Regards,
David
Re: Apache::TestMB
Oops, sorry for the dupe. David
Re: Apache::TestMB
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 Clocal $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 BekmanJAm_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
Re: [Module::Build] Re: Apache::TestMB
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
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: Apache::TestMB
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 BekmanJAm_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
Re: Apache::TestMB
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 Cmake 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
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 Cmake 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 BekmanJAm_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
Re: Apache::TestMB
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
