Doug MacEachern wrote:
> On Fri, 21 Sep 2001, Stas Bekman wrote:
>
>
>>Please consider the following scenario:
>>
>>% ./t/TEST -clean
>>% ./t/TEST api
>>
>>In the current setup, -clean deletes all autogenerated test files. Now the
>>second command is supposed to run all tests in t/api, but alas, most of
>>them weren't created yet, when the directory t/api is scanned for
>>t/api/*.t. Hence most of the tests won't be run.
>>
>>The following patch fixes that, but it enforces something that wasn't
>>enforced so far. The configuration options has to start with - or -- to be
>>accepted, just like ./t/TEST -help advertises. So we have to fix the docs
>>to use '-apxs foo' and not just 'apxs foo'.
>>
>>I know it's probably hard to change habits, but the current setup is not
>>clean, since you may miss a lot of tests, when you think you've run them
>>all. Since we aim to have Apache::Test working for other projects, I think
>>it'd be great to fix it as early as possible. I'll fix the docs if
>>accepted (including httpd-test).
>>
>
> that sounds fine.
>
>
>>So the new setup parses @ARGV 3 times
>>
>> 1. GetOptions (options)
>> 2. Configuration options
>> 3. test files/dirs
>>
>>The stage 3 happens only after the server is ready to run, i.e. when all
>>the auto-generated tests are created already, so t/api/*.t will pick all
>>the tests.
>>
>>There is one more flow that I've noticed -- if you run:
>>./t/TEST apxs foo/bar
>>after the configuration has been built already, the new values don't take
>>effect and simply ignored. I think they should cause refresh.
>>
>
> yes it should, and does for me in current cvs. could be your patch
> changed that behavior? please make sure your patch does not break that
> feature.
I've fixed this problem and committed the new functionality.
Note that I still allow configuration options without leading - or --,
but at the same time I allow now those with - or -- as we advertise in
the output of ./t/TEST --help
Now, I think we should enforce a leading - and not allow plain words.
Consider a situation where there is a test dir called apxs, because we
decided to test apxs. In the current setup this would be impossible.
(just like in the previous, if this dir was autogenerated)
There are more problems that I've notices. e.g.:
If I build perl Makefile.PL with prefork mod_perl, but then run the test
with the threaded one
./t/TEST -apxs /home/stas/httpd/threaded/bin/apxs
the configuration changes partially, e.g. Apache::BuildConfig doesn't
change. So if you run 'perl build/config.pl' you get the prefork options
and not the new ones passed via apxs. This is how it was before I've
committed my latest change.
I'm kinda unsure what the ./t/TEST configuration option are supposed to
do. What's the scope of the change and etc. It doesn't seem clean to me.
Another problem: If I try to override configuration options in
httpd-test/perl-framework they are ignored. Again, tested with the new
TestRun.pm and the old one -- I see the same behavior. Try:
% /home/stas/perl/ithread/bin/perl5.7.2 Makefile.PL apxs
/home/stas/httpd/prefork/bin/apxs
% ./t/TEST
% ./t/TEST apxs /home/stas/httpd/threaded/bin/apxs
it still invokes the prefork server, I cannot figure out why...
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
