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 Stas Bekman <st...@stason.org> on 2003/11/07 19:56:57 UTC
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfigParse.pm
geoff@apache.org wrote:
> geoff 2003/11/07 07:03:39
>
> Modified: perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
> Log:
> use apxs PREFIX to resolve relative httpd.conf directives
> ServerRoot is not present
>
> Revision Changes Path
> 1.36 +48 -6 httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm
>
> Index: TestConfigParse.pm
[...]
> + else {
> + warning "unable to resolve $file - cannot find a suitable ServerRoot";
> + warning "please specify a ServerRoot in your httpd.conf or use apxs";
shouldn't this be an error message (not fatal, just s/warning/error/)
__________________________________________________________________
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfigParse.pm
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>> actually, the 'errors' might not end up being errors at all - if the
>>> configuration script can't resolve conf/mime.types, for instance, but
>>> the EU has one in his t/conf directory everything should work out fine.
>>
>>
>>
>> if that's the case, why not having A-T look in that directory and keep
>> things under a tight control.
>
>
> yeah. but I'm not exactly sure what the proper behavior here ought to
> be, and there are lots of variables (like conf/foo.in which may not
> change into conf/foo before TestConfigParse looks for it).
>
> at any rate, I think we can delay the digging for a while - Mike's
> original problem has been addressed and we've added in a few extra
> checks and debugging, so if something like this crops up in real life it
> will be easy to address.
Certainly. We have enough real problems to tend to first ;)
__________________________________________________________________
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfigParse.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> actually, the 'errors' might not end up being errors at all - if the
>> configuration script can't resolve conf/mime.types, for instance, but
>> the EU has one in his t/conf directory everything should work out fine.
>
>
> if that's the case, why not having A-T look in that directory and keep
> things under a tight control.
yeah. but I'm not exactly sure what the proper behavior here ought to be,
and there are lots of variables (like conf/foo.in which may not change into
conf/foo before TestConfigParse looks for it).
at any rate, I think we can delay the digging for a while - Mike's original
problem has been addressed and we've added in a few extra checks and
debugging, so if something like this crops up in real life it will be easy
to address.
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfigParse.pm
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> geoff@apache.org wrote:
>>
>>> geoff 2003/11/07 07:03:39
>>>
>>> Modified: perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
>>> Log:
>>> use apxs PREFIX to resolve relative httpd.conf directives
>>> ServerRoot is not present
>>> Revision Changes Path
>>> 1.36 +48 -6
>>> httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm
>>> Index: TestConfigParse.pm
>>
>>
>> [...]
>>
>>> + else {
>>> + warning "unable to resolve $file - cannot find a
>>> suitable ServerRoot";
>>> + warning "please specify a ServerRoot in your
>>> httpd.conf or use apxs";
>>
>>
>>
>> shouldn't this be an error message (not fatal, just s/warning/error/)
>
>
> well, I was thinking about that lots. the reason I went with warning is
> that under normal circumstances 'perl Makefile.PL' would be the one
> throwing the message, but it's really not a build-time problem.
> actually, the 'errors' might not end up being errors at all - if the
> configuration script can't resolve conf/mime.types, for instance, but
> the EU has one in his t/conf directory everything should work out fine.
if that's the case, why not having A-T look in that directory and keep things
under a tight control.
> so, given this, I thought warnings were more appropriate. but I'm
> flexible and don't feel too strongly about it.
sure, let's keep it as it is for now.
__________________________________________________________________
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfigParse.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> geoff@apache.org wrote:
>
>> geoff 2003/11/07 07:03:39
>>
>> Modified: perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
>> Log:
>> use apxs PREFIX to resolve relative httpd.conf directives
>> ServerRoot is not present
>> Revision Changes Path
>> 1.36 +48 -6
>> httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm
>> Index: TestConfigParse.pm
>
> [...]
>
>> + else {
>> + warning "unable to resolve $file - cannot find a
>> suitable ServerRoot";
>> + warning "please specify a ServerRoot in your httpd.conf
>> or use apxs";
>
>
> shouldn't this be an error message (not fatal, just s/warning/error/)
well, I was thinking about that lots. the reason I went with warning is
that under normal circumstances 'perl Makefile.PL' would be the one throwing
the message, but it's really not a build-time problem. actually, the
'errors' might not end up being errors at all - if the configuration script
can't resolve conf/mime.types, for instance, but the EU has one in his
t/conf directory everything should work out fine.
so, given this, I thought warnings were more appropriate. but I'm flexible
and don't feel too strongly about it.
--Geoff