httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
Date Fri, 02 Apr 2004 01:26:16 GMT
Geoffrey Young wrote:
>>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.

That's what Ken wanted

> perhaps I wasn't clear enough, but the proposed 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?

Please see below

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

No, have_module() won't see those modules. It must be parsed via inheriting 
scheme or come up with a new way. the new option seems to be the simplest 

Ken doesn't want it to be inside t/conf/, since he will have it elsewhere. He 
doesn't want to touch the A-T project's file. That's what I understood.

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

But again, this is something to consider in the future.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message