Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigParse.pm

2003-11-07 Thread Stas Bekman 
[EMAIL PROTECTED] 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  ChangesPath
  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 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigParse.pm

2003-11-07 Thread Geoffrey Young 

Stas Bekman wrote:
[EMAIL PROTECTED] 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  ChangesPath
  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

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigParse.pm

2003-11-07 Thread Stas Bekman 
Geoffrey Young wrote:

Stas Bekman wrote:
[EMAIL PROTECTED] 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  ChangesPath
  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 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigParse.pm

2003-11-07 Thread Geoffrey Young 

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