[EMAIL PROTECTED] 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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
