You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@perl.apache.org by "Christopher H. Laco" <cl...@chrislaco.com> on 2005/04/15 00:51:14 UTC
Module::Build+Apache::Test config looping issues redux
This is an all out please for help form someone who understands the
structure of A-T a little better than I.
Just to recap, under ExtUtils::MakeMaker, 'make test' reads the location
of Apache.exe just fine for me. 'perl Build test' fails to read or
receive the value and enters a continous loop asking for the Apache.exe
location.
I've started from TestMB::ACTION_test and worked my way down to this sub
in TestConfig:
> sub custom_config_add_conf_opts {
> my $args = shift;
>
> return unless $Apache::TestConfigData::vars and
> keys %$Apache::TestConfigData::vars;
Under E::M, $Apache::TestConcifgData::vars has the httpd key and the
path value. Under M::B, $Apache::TestConfigData::vars is undefined at
this point.
I'm trying to spot where this gets pulled in since that seems to be the
problem [or the ENV mapping of httpd->APACHE_TEST_HTTPD is happening
differently under M::B), but I'm just missing it.
Someone smack me with the clue stick please.
Thanks.
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
> Thanks for the explaination, Chris. It's clear now.
>
> As I've mentioned t/SMOKE is usually run after t/TEST fails, so it has
> always relied on the fact that 'make test' was already run and therefore
> didn't require to run its own setup.
>
> Patches to make it independent are very welcome.
I might take a stab at it if I can get my brain around which to focus on
(TestSMoke or TestSmokePerl)...
Thanks,
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
> David Wheeler wrote:
>
>> On Apr 18, 2005, at 9:53 AM, Stas Bekman wrote:
>>
>>> As I've mentioned t/SMOKE is usually run after t/TEST fails, so it
>>> has always relied on the fact that 'make test' was already run and
>>> therefore didn't require to run its own setup.
>>
>>
>>
>> Should `make smoke` rely on `make test`, then?
>
>
> % make smoke
> make: *** No rule to make target `smoke'. Stop.
>
> But if you wish to make it so, I've no objections :)
>
Sigh. Stop giving me ideas. :-)
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by David Wheeler <da...@kineticode.com>.
On Apr 18, 2005, at 7:23 PM, Stas Bekman wrote:
> % make smoke
> make: *** No rule to make target `smoke'. Stop.
>
> But if you wish to make it so, I've no objections :)
No, I have no interest in smoke (thank god!).
Cheers,
David
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Apr 18, 2005, at 9:53 AM, Stas Bekman wrote:
>
>> As I've mentioned t/SMOKE is usually run after t/TEST fails, so it has
>> always relied on the fact that 'make test' was already run and
>> therefore didn't require to run its own setup.
>
>
> Should `make smoke` rely on `make test`, then?
% make smoke
make: *** No rule to make target `smoke'. Stop.
But if you wish to make it so, I've no objections :)
--
__________________________________________________________________
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+Apache::Test config looping issues redux
Posted by David Wheeler <da...@kineticode.com>.
On Apr 18, 2005, at 9:53 AM, Stas Bekman wrote:
> As I've mentioned t/SMOKE is usually run after t/TEST fails, so it has
> always relied on the fact that 'make test' was already run and
> therefore didn't require to run its own setup.
Should `make smoke` rely on `make test`, then?
Regards,
David
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>> I meant, that I don't understand why do you get stuck at t/SMOKE? Are
>> you trying to use it and it's not working? Or is it the TestMB that
>> tries to create it and fails the whole thing, when you don't even want
>> t/SMOKE? You really need t/TEST for the test suite. t/SMOKE is for
>> advanced testing/debugging.
>>
>>
>
> Oh, I see. Let's forget that I ever mentioned Module::Build and TestMB
> for a moment and stay in the realm of ExtUtils::MakeMaker.
>
> Let's assume I've created a TEST.PL, SMOKE.PL and a Makefile.PL that
> calls generate_script("t/TEST") and generate_script("t/SMOKE").
>
> If I run:
>
> perl Makefile.PL
> make
> perl t/TEST t/sometest
>
>
> everything works fine. t/conf/apache_test_config.pm is auto-generated
> with the expected data from TestConfigData.pm.
>
> Now, do a make distclean to start from scratch.
>
> Now I run:
>
> perl Makefile.PL
> make
> perl t/SMOKE
>
> t/conf/apache_test_config.pm is NOT generated, nor is any other file in
> t/conf. This is what starts the endless "where's apache.exe" loop for me
> under win32.
>
> The lack of autogenerated A-T config files leads to the assumption that
> using t/SMOKE REQUIRES that you first run t/TEST to autogenerate the
> configs.
Thanks for the explaination, Chris. It's clear now.
As I've mentioned t/SMOKE is usually run after t/TEST fails, so it has
always relied on the fact that 'make test' was already run and therefore
didn't require to run its own setup.
Patches to make it independent are very welcome.
> I don't remeber reading that requirement anywhere and was curious if
> perl t/SMOKE show act exactly like t/TEST and qutogenerate the needed
> t/conf files.
--
__________________________________________________________________
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+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
> I meant, that I don't understand why do you get stuck at t/SMOKE? Are
> you trying to use it and it's not working? Or is it the TestMB that
> tries to create it and fails the whole thing, when you don't even want
> t/SMOKE? You really need t/TEST for the test suite. t/SMOKE is for
> advanced testing/debugging.
>
>
Oh, I see. Let's forget that I ever mentioned Module::Build and TestMB
for a moment and stay in the realm of ExtUtils::MakeMaker.
Let's assume I've created a TEST.PL, SMOKE.PL and a Makefile.PL that
calls generate_script("t/TEST") and generate_script("t/SMOKE").
If I run:
perl Makefile.PL
make
perl t/TEST t/sometest
everything works fine. t/conf/apache_test_config.pm is auto-generated
with the expected data from TestConfigData.pm.
Now, do a make distclean to start from scratch.
Now I run:
perl Makefile.PL
make
perl t/SMOKE
t/conf/apache_test_config.pm is NOT generated, nor is any other file in
t/conf. This is what starts the endless "where's apache.exe" loop for me
under win32.
The lack of autogenerated A-T config files leads to the assumption that
using t/SMOKE REQUIRES that you first run t/TEST to autogenerate the
configs.
I don't remeber reading that requirement anywhere and was curious if
perl t/SMOKE show act exactly like t/TEST and qutogenerate the needed
t/conf files.
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>> Christopher H. Laco wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>> I've CC'ed David, who developed Apache::TestMB, so he will hopefully
>>>> be able to give you the answers.
>>>>
>>>> David, please take a look at this thread. I can't give you the link,
>>>> since I don't think this new list is archived at all. Are you
>>>> subscribed to it at all?
>>>>
>>>
>>> Thanks for the forward.
>>> Any thoughts about the other issue; whether t/SMOKE | TestSmoke
>>> should autogen the configurations just like t/TEST | TestRunScript does?
>>
>>
>>
>> What I don't understand is why do you have anything to do with t/SMOKE?
>
>
> I'm not sure I understand that statement. Do you mean why I'm talking
> about t/SMOKE instead of t/SMOKE.PL; or why I even have a t/SMOKE.PL or
> smoke testing period?
I meant, that I don't understand why do you get stuck at t/SMOKE? Are you
trying to use it and it's not working? Or is it the TestMB that tries to
create it and fails the whole thing, when you don't even want t/SMOKE? You
really need t/TEST for the test suite. t/SMOKE is for advanced
testing/debugging.
--
__________________________________________________________________
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+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
> Christopher H. Laco wrote:
>
>> Stas Bekman wrote:
>>
>>> I've CC'ed David, who developed Apache::TestMB, so he will hopefully
>>> be able to give you the answers.
>>>
>>> David, please take a look at this thread. I can't give you the link,
>>> since I don't think this new list is archived at all. Are you
>>> subscribed to it at all?
>>>
>>
>> Thanks for the forward.
>> Any thoughts about the other issue; whether t/SMOKE | TestSmoke should
>> autogen the configurations just like t/TEST | TestRunScript does?
>
>
> What I don't understand is why do you have anything to do with t/SMOKE?
I'm not sure I understand that statement. Do you mean why I'm talking
about t/SMOKE instead of t/SMOKE.PL; or why I even have a t/SMOKE.PL or
smoke testing period?
-=CHris
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Christopher H. Laco wrote:
>
>> 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?
>>
>> -=Chris
>
>
> Is there any reason that TestSmokePerl can't/shouldn't use or include
> configure_modperl/pre_configure from TestRunPerl rather than using"
>
>> use ModPerl::Config ();
>>
>> sub build_config_as_string {
>> ModPerl::Config::as_string();
>> }
The two have nothing to do with each other. build_config_as_string is only
used to generate reports (ala mp2bug). again, start with TestSmoke and
then add overrides in TestSmokePerl if anything needs to be overriden.
--
__________________________________________________________________
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+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Christopher H. Laco wrote:
> 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?
>
> -=Chris
Is there any reason that TestSmokePerl can't/shouldn't use or include
configure_modperl/pre_configure from TestRunPerl rather than using"
> use ModPerl::Config ();
>
> sub build_config_as_string {
> ModPerl::Config::as_string();
> }
?
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
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?
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?
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.
>
>> 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"...
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?
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Christopher H. Laco wrote:
>
>> So According to
>> http://perl.apache.org/docs/general/testing/testing.html#C_Apache__TestSmoke__Solution
>>
>>
>> The sample t/SMOKE.PL files is:
>>
>> #file:t/SMOKE.PL
>> #---------------
>> #!perl
>>
>> use strict;
>> use warnings FATAL => 'all';
>>
>> use FindBin;
>> use lib "$FindBin::Bin/../Apache-Test/lib";
>> use lib "$FindBin::Bin/../lib";
>>
>> use Apache::TestSmoke ();
>>
>> Apache::TestSmoke->new(@ARGV)->run;
>>
>>
>> That uses TestSmoke, not TestSmokePerl [directly] like I would expect
>> That's what I currently have in my t/SMOKE.PL [sans FindBin stuffs].
>> I tried using a t/SMOKE.PL that used TestSmokePerl instead of
>> TestSmoke. It wasn't pretty. :-)
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.
> 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.
--
__________________________________________________________________
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+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Christopher H. Laco wrote:
> So According to
> http://perl.apache.org/docs/general/testing/testing.html#C_Apache__TestSmoke__Solution
>
>
> The sample t/SMOKE.PL files is:
>
> #file:t/SMOKE.PL
> #---------------
> #!perl
>
> use strict;
> use warnings FATAL => 'all';
>
> use FindBin;
> use lib "$FindBin::Bin/../Apache-Test/lib";
> use lib "$FindBin::Bin/../lib";
>
> use Apache::TestSmoke ();
>
> Apache::TestSmoke->new(@ARGV)->run;
>
>
> That uses TestSmoke, not TestSmokePerl [directly] like I would expect
> That's what I currently have in my t/SMOKE.PL [sans FindBin stuffs].
> I tried using a t/SMOKE.PL that used TestSmokePerl instead of TestSmoke.
> It wasn't pretty. :-)
>
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.
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?
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
>> For that matter, why does t/TEST use TestRunPerl while t/SMOKE uses
>> TestSmoke? I would've expected TestSmokePerl [no knowing yet the
>> difference between the two].
>
>
> Apache::TestRunPerl is a subclass of Apache::TestPerl, which overrides
> some method.
>
> SMOKE generated by mod_perl/EU::MM does use Apache::TestSmokePerl. There
> must be something different about TestMB, I guess.
>
>
That's where I get confused. By default, nothing automatically generates
a t/SMOKE file correct? One must first create a t/SMOKE.PL and call
generate_script("t/SMOKE").
So According to
http://perl.apache.org/docs/general/testing/testing.html#C_Apache__TestSmoke__Solution
The sample t/SMOKE.PL files is:
#file:t/SMOKE.PL
#---------------
#!perl
use strict;
use warnings FATAL => 'all';
use FindBin;
use lib "$FindBin::Bin/../Apache-Test/lib";
use lib "$FindBin::Bin/../lib";
use Apache::TestSmoke ();
Apache::TestSmoke->new(@ARGV)->run;
That uses TestSmoke, not TestSmokePerl [directly] like I would expect
That's what I currently have in my t/SMOKE.PL [sans FindBin stuffs].
I tried using a t/SMOKE.PL that used TestSmokePerl instead of TestSmoke.
It wasn't pretty. :-)
However, t/TEST.PL at
http://perl.apache.org/docs/general/testing/testing.html#Basic_Testing_Environment
#file:t/TEST.PL
#--------------
#!perl
use strict;
use warnings FATAL => 'all';
use lib qw(lib);
use Apache::TestRunPerl ();
Apache::TestRunPerl->new->run(@ARGV);
uses TestRunPerl, not TestRun as expected.
So, I'm still a little confused on the difference between TestSmoke and
TestSmokePerl in the context of SMOKE.PL since it's the opposite
name-wise of what happens in TEST.PL....if that makes any sense at all.
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>> I've CC'ed David, who developed Apache::TestMB, so he will hopefully
>> be able to give you the answers.
>>
>> David, please take a look at this thread. I can't give you the link,
>> since I don't think this new list is archived at all. Are you
>> subscribed to it at all?
>>
>
> Thanks for the forward.
> Any thoughts about the other issue; whether t/SMOKE | TestSmoke should
> autogen the configurations just like t/TEST | TestRunScript does?
What I don't understand is why do you have anything to do with t/SMOKE?
> For that matter, why does t/TEST use TestRunPerl while t/SMOKE uses
> TestSmoke? I would've expected TestSmokePerl [no knowing yet the
> difference between the two].
Apache::TestRunPerl is a subclass of Apache::TestPerl, which overrides
some method.
SMOKE generated by mod_perl/EU::MM does use Apache::TestSmokePerl. There
must be something different about TestMB, I guess.
--
__________________________________________________________________
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+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
> I've CC'ed David, who developed Apache::TestMB, so he will hopefully be
> able to give you the answers.
>
> David, please take a look at this thread. I can't give you the link,
> since I don't think this new list is archived at all. Are you subscribed
> to it at all?
>
Thanks for the forward.
Any thoughts about the other issue; whether t/SMOKE | TestSmoke should
autogen the configurations just like t/TEST | TestRunScript does?
For that matter, why does t/TEST use TestRunPerl while t/SMOKE uses
TestSmoke? I would've expected TestSmokePerl [no knowing yet the
difference between the two].
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
I've CC'ed David, who developed Apache::TestMB, so he will hopefully be
able to give you the answers.
David, please take a look at this thread. I can't give you the link, since
I don't think this new list is archived at all. Are you subscribed to it
at all?
Christopher H. Laco wrote:
> Christopher H. Laco wrote:
>
>> So, apparently it's trying to run the last script created via
>> generate_script instead of always running t/TEST.
>>
>> -=Chris
>
>
> And the offending part of the code ffrom TestMB.pm:
>
>> my $script = $self->localize_file_path($_[0]
>> ? $self->apache_test_script(shift)
>> : $self->apache_test_script
>> );
>
>
>
> So, which behavour is correct, TestMM::generate_script or
> TestMB::generate_script? Only TestMB takes the last file called in
> generate_script and makes it apache_test_script in build_params.
>
> TestMM always runs t/TEST it seems, regardless of the order of calls to
> generate_script.
>
> Now that it's identified, it's easy to reorder my generate_script calls
> under Build.PL and get where I need to go. I would think that both
> generate_scripts should do the same thing.
>
> There's still the issue of t/SMOKE not auto generating t/conf/* files
> like t/TEST does.
>
> Thanks for the help.
>
> -=Chris
>
>
--
__________________________________________________________________
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+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Christopher H. Laco wrote:
> So, apparently it's trying to run the last script created via
> generate_script instead of always running t/TEST.
>
> -=Chris
And the offending part of the code ffrom TestMB.pm:
> my $script = $self->localize_file_path($_[0]
> ? $self->apache_test_script(shift)
> : $self->apache_test_script
> );
So, which behavour is correct, TestMM::generate_script or
TestMB::generate_script? Only TestMB takes the last file called in
generate_script and makes it apache_test_script in build_params.
TestMM always runs t/TEST it seems, regardless of the order of calls to
generate_script.
Now that it's identified, it's easy to reorder my generate_script calls
under Build.PL and get where I need to go. I would think that both
generate_scripts should do the same thing.
There's still the issue of t/SMOKE not auto generating t/conf/* files
like t/TEST does.
Thanks for the help.
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
William McKee wrote:
>>I'm just spouting thoughts hoping it rings someone elses bell... sorry.
>
>
> This reminds me of a discussion that took place recently on the MB
> mailing list[1]. I wonder what would happen if you leave SMOKE.PL but
> comment out all the code. Do the die statements get called? Perhaps
> something in that code is short-circuting A::T.
>
>
> William
>
> [1] http://sourceforge.net/mailarchive/forum.php?thread_id=6951616&forum_id=10905
>
I think I've found the culprit.
If I do:
perl Makefile.PL
(which calls generate_script for TEST.PL and then SMOKE.PL)
perl t/TEST
perl t/SMOKE
Everything runs as expected. However if I do:
perl Makefile.PL
perl t/SMOKE
it starts the endless "where's apache" loop. I'm assuming that is
because t/conf/apache_test_config.pm has not yet been generated by
running t/TEST || TestRunPerl.
Is that expected, or is that a bug?
Now this problem cropped up because M::B, or TestMB is inadvertantly
trying to run SMOKE instead of TEST during 'perl Build test'.
Even more fascinating....
If I switch:
> $build->generate_script('t/TEST');
> $build->generate_script('t/SMOKE');
to this:
> $build->generate_script('t/SMOKE');
> $build->generate_script('t/TEST');
perl Build test runs just fine...and perl t/SMOKE then runs fine as
well. And just for a laugh....
> $build->generate_script('t/SMOKE');
> $build->generate_script('t/TEST');
> $build->generate_script('t/POOP');
yields:
> C:\Development\CPAN\Handel>perl Build test
> C:\Development\Perl\584\bin\perl.exe -I C:\Development\CPAN\Handel\blib\lib -I C:\Development\CPAN\Handel\blib\arch t\POOP -clean
So, apparently it's trying to run the last script created via
generate_script instead of always running t/TEST.
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by William McKee <wi...@knowmad.com>.
> I'm just spouting thoughts hoping it rings someone elses bell... sorry.
This reminds me of a discussion that took place recently on the MB
mailing list[1]. I wonder what would happen if you leave SMOKE.PL but
comment out all the code. Do the die statements get called? Perhaps
something in that code is short-circuting A::T.
William
[1] http://sourceforge.net/mailarchive/forum.php?thread_id=6951616&forum_id=10905
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Christopher H. Laco wrote:
> Great...two problems in one.
> I was not seeing my dies because even though my Build.PL has:
>
>> $build->generate_script('t/TEST');
>> $build->generate_script('t/SMOKE');
>
>
> The output from perl Build test is:
>
>> C:\Development\CPAN\Handel>perl Build test -verbose
>> C:\Development\Perl\584\bin\perl.exe -I
>> C:\Development\CPAN\Handel\blib\lib -I
>> C:\Development\CPAN\Handel\blib\arch t\SMOKE -clean
>
>
> So on top of the config issue, it's running t/SMOKE first, and t/TEST is
> no where in sight....
>
> The same goes for:
>
>>> #$build->generate_script('t/TEST');
>>> $build->generate_script('t/SMOKE');
>
>
>
> -=Chris
So, it looks like SMOKE.PL is triggering my problem.
Question. t/TEST.PL runs TestRunPerl, but t/SMOKE.PL runs TestSmoke, and
not TestSmokePerl. Is that right? I'd guess so since smoking worked
under EU::MM
For that matter, t/SMOKE shouldn't even be run during test. It should
just be t/TEST period. So maybe it's not that SMOKE.PL is causing
problems at all, but maybe M::B it trying to run the wrong thing....
Nope... perl t/SMOKE is broken when generated by M::B, but works when
generated via EU::MM...
I'm just spouting thoughts hoping it rings someone elses bell... sorry.
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Christopher H. Laco wrote:
>> Right, it must be run at test time.
>>
> I've worked my way though all of the custom_config_loads and
> custom_config_exists I can find, and die-ing before any of them doesn't
> make perl Build test die. :-(
>
> This is a tough one...
Great...two problems in one.
I was not seeing my dies because even though my Build.PL has:
> $build->generate_script('t/TEST');
> $build->generate_script('t/SMOKE');
The output from perl Build test is:
> C:\Development\CPAN\Handel>perl Build test -verbose
> C:\Development\Perl\584\bin\perl.exe -I C:\Development\CPAN\Handel\blib\lib -I C:\Development\CPAN\Handel\blib\arch t\SMOKE -clean
So on top of the config issue, it's running t/SMOKE first, and t/TEST is
no where in sight....
The same goes for:
>> #$build->generate_script('t/TEST');
>> $build->generate_script('t/SMOKE');
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
> Christopher H. Laco wrote:
>
>> Christopher H. Laco wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>>
>>>> Chris, grep for custom_config_load() which loads that data. and see
>>>> why Build doesn't pick it up.
>>>>
>>>
>>> Found it. Should that be called during a test run, or just during the
>>> build?
>>>
>>> IF I slap a die right inside or custom_config_load, it doesn't die
>>> during 'perl Build test'
>>>
>>> -=Chris
>>>
>>>
>> Which [duh] is probably the problem. :-)
>
>
> Right, it must be run at test time.
>
I've worked my way though all of the custom_config_loads and
custom_config_exists I can find, and die-ing before any of them doesn't
make perl Build test die. :-(
This is a tough one...
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Christopher H. Laco wrote:
>
>> Stas Bekman wrote:
>>
>>>
>>> Chris, grep for custom_config_load() which loads that data. and see
>>> why Build doesn't pick it up.
>>>
>>
>> Found it. Should that be called during a test run, or just during the
>> build?
>>
>> IF I slap a die right inside or custom_config_load, it doesn't die
>> during 'perl Build test'
>>
>> -=Chris
>>
>>
> Which [duh] is probably the problem. :-)
Right, it must be run at test time.
--
__________________________________________________________________
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+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>>
>> Chris, grep for custom_config_load() which loads that data. and see
>> why Build doesn't pick it up.
>>
>
> Found it. Should that be called during a test run, or just during the
> build?
>
> IF I slap a die right inside or custom_config_load, it doesn't die
> during 'perl Build test'
>
> -=Chris
>
>
Which [duh] is probably the problem. :-)
Re: Module::Build+Apache::Test config looping issues redux
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
>
> Chris, grep for custom_config_load() which loads that data. and see why
> Build doesn't pick it up.
>
Found it. Should that be called during a test run, or just during the build?
IF I slap a die right inside or custom_config_load, it doesn't die
during 'perl Build test'
-=Chris
Re: Module::Build+Apache::Test config looping issues redux
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> This is an all out please for help form someone who understands the
> structure of A-T a little better than I.
>
> Just to recap, under ExtUtils::MakeMaker, 'make test' reads the location
> of Apache.exe just fine for me. 'perl Build test' fails to read or
> receive the value and enters a continous loop asking for the Apache.exe
> location.
>
> I've started from TestMB::ACTION_test and worked my way down to this sub
> in TestConfig:
>
>> sub custom_config_add_conf_opts {
>> my $args = shift;
>>
>> return unless $Apache::TestConfigData::vars and
>> keys %$Apache::TestConfigData::vars;
>
>
>
>
> Under E::M, $Apache::TestConcifgData::vars has the httpd key and the
> path value. Under M::B, $Apache::TestConfigData::vars is undefined at
> this point.
>
> I'm trying to spot where this gets pulled in since that seems to be the
> problem [or the ENV mapping of httpd->APACHE_TEST_HTTPD is happening
> differently under M::B), but I'm just missing it.
>
> Someone smack me with the clue stick please.
Chris, grep for custom_config_load() which loads that data. and see why
Build doesn't pick it up.
--
__________________________________________________________________
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