[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-test-cvs
Subject:    Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
From:       Stas Bekman <stas () stason ! org>
Date:       2004-04-02 1:07:22
Message-ID: 406CBCCA.8000807 () stason ! org
[Download RAW message or body]

Geoffrey Young wrote:
> 
> coar@apache.org wrote:
> 
>>coar        2004/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 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
[prev in list] [next in list] [prev in thread] [next in thread]