httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
Date Fri, 02 Apr 2004 01:20:01 GMT

> 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).

right, I think I got that.  but that requires knowing the hard-coded path.
perhaps I wasn't clear enough, but the proposed httpd.extra.conf.in would be
appended to the generated httpd.conf rather than pulled in via Include.
would that not suit the needs that the current patch resolves?

> 
> 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.

would there really be a need to pull in more than one config into the main
httpd.conf that couldn't be met via Include?

> 
> 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).

yes, it's a separate issue but a good idea as well.

--Geoff

Mime
View raw message