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

Reply via email to