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

2004-04-02 Thread Stas Bekman
Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
coar2004/04/01 15:57:17
 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
   TestConfigParse.pm
 Log:
add an '-httpd_conf_extra filename' option to allow
an *additional* server config file to be inherited as
well as the server's main one (or one specified with
-httpd_conf).

ok, I guess you guys figured out how to do it :)
Looks like Ken's hair started to grow again, after he had it all lost over 
this case :)

anyway, if I can interject a few comments on the idea...
we already have a few files that get magical treatment: extra.conf.in,
extra.last.conf.in, modperl_startup.pl, etc.  I think the way I would do it
(from afar :) is to create yet another special case, maybe
httpd.extra.conf.in or somesuch.  advantages would be that it would follow
the approach we've been using, it wouldn't require an extra runtime
argument, and it could benefit from variable subsitution like all the other
conf files.
That probably won't suite Ken's particular need. What Ken was after is to be 
able to throw random .so modules into some directory and tell Apache::Test to 
detect them, load them and have have_module() see them. and Ken really wants 
to have lots of these directories and point every time to a different one. So 
all he does now is generating a simple extra.conf which only lists LoadModule 
directives with the correct path to those modules, A-T picks them up and 
doesn't require c-modules any longer (Ken wants to pre-build c-modules for 
many architectures and many apache versions).

I like this Ken's new option because it'll suite cases where a user can't 
modify the global httpd.conf, but will be able to add its own global 
httpd.conf extra's via this option. We have also discussed to make it accept 
more than one file, but at the moment it's not possible and will require quite 
a few changes (currently config is a hash and it's set in more than one 
place). doable, but we probably shouldn't touch it until someone will really 
need it.

While we discussed possible solutions, I suggested an idea to figure out 
whether we have a compiler at all, and if not skip even trying to build 
c-modules. So if you build things on machine A with a compiler and then tar 
things up and move it to machine B w/o a compiler (same architecture), the 
modules will be already precompiled and ready to use and t/TEST -clean won't 
nuke them. Ken said that this idea didn't suite him, but I think it could be 
useful to others. The kludge is how to figure out whether things will be able 
to compile or not (whether there is a compiler at all).

__
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 TestUtil.pm

2001-10-20 Thread Stas Bekman
[EMAIL PROTECTED] wrote:
dougm   01/10/19 22:02:05
  Modified:perl-framework/Apache-Test/lib/Apache TestUtil.pm
  Log:
  function to write a shell script for unix, bat for win32
...
  +sub write_shell_script {

shouldn't this be t_write_shell_script in complience with the naming of other methods in this module? 

Or is it ok, since it's not exported?

_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/