Stas Bekman wrote:
When you see Perl in the class name, it really means ModPerl-specific. i.e. it's a subclass that *requires* mod_perl and needed to be be able to run under mod_perl.
And maybe that's my issue.
After looking at it again, I get the feeling that t/SMOKE for an A-T dist using mod_perl really wants to use TestSmokePerl instead of TestSmoke; and TestSmokePerl looks much much thinner than TestRunPerl in terms of the mod_perl configuration steps in the module.
No. A-T is not mod_perl specific, therefore it's t/SMOKE must not require mod_perl.
That seems wrong to me. MUST not, or _may_not_be?
It must not *require* mod_perl, i.e. it should be working regardless of whether mod_perl is available or not.
I can call TestRun->generate_script or TestRunPerl->generate_script to generate t/TEST that either does or doesn't require mod_perl setup.
If would think then that t/SMOKE should use TestSmoke or TestSmokePerl to require or not require modperl when calling t/SMOKE in the exact same way right?
That's correct.
I'm not trying to be a pain in the butt [really I'm not :-)], it's just that the two sides; TEST vs. SMOKE, don't act alike when they use their respective Test* vs. Test*Perl modules.
It's quite possible. When I wrote SMOKE my ambitions were different. You aren't certainly not a pain in the butt. I could certainly go and try to code the missing part, but if one more person can learn the code, I'd rather help to get the required understanding. so don't worry what you ask, Chris.
Assuming it's the right thing to do, adding the mod_perl config stuff into TestSmokePerl from TestRunPerl shouldn't be too difficult.
I'm afraid of breaking anything that uses TestSmokePerl, but it doesn't appear like much, if anything does?
All the changes should go into base class, which is TestSmoke. TestSmokePerl should have only modperl specific things, just like ModPerl::TestRun subclasses Apache::TestRun.
I would've expected the to read:
"TestSmokePerl should have only modperl specific things, just like TestRunPerl"...
right, sorry. ModPerl::TestRun is a subclass of Apache::TestRunPerl. So what happens is:
Apache::TestRunPerl - for any module Apache::TestRunPerl - for any module running under mod_perl ModPerl::TestRun - for mod_perl core specific test suite
So we probably shouldn't even install ModPerl::TestRun, since it's core's 'make test'-specific. I think it should be moved into t/lib/
But while we are refactoring this may be it should be renamed to TestRunModPerl? Geoff?
I guess I need to keep digging and try and understand the structure better.
While I'm being a pain in the butt, I've seen all three of these variations:
Apache::TestMM::generate_script("t/TEST") Apache::TestRun->generate_script("t/TEST") Apache::TestRunPerl->generate_script("t/TEST")
floating around. The last two as pretty straight forward...why would one want to use the first example? Does it try to guess between the latter two?
The first one processes an existing TEST.PL file, adding whatever it needs to add to create TEST e.g. ModPerl-Registry/Makefile.PL processes ModPerl-Registry/t/TEST.PL this way.
Other 2, generate t/TEST from scratch. So most of the time, you just tell A-T to generate t/TEST for you. But sometimes it's not good enough, so you create a "template" t/TEST.PL and let A-T complete it. Again see the example of ModPerl-Registry/t/TEST.PL to see the difference.
-- __________________________________________________________________ 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