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