>> right, I think I got that. but that requires knowing the hard-coded >> path. > > > That's what Ken wanted
ok, but just because you get substitution doesn't mean you have to use it :) > >> 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 >> 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. I don't see your point here. once you splice together the current httpd.conf with the new file (however it's generated) have_module would have access to the information it needs. > > 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. ok, that's a valid reason. anyway I was just making a suggestion - it seems limiting to me not to have substitution in extra configuration files, or to be able to specify one kind of config file from the command line but not others. but it's not like I have the tuits to do anything about it now anyway, so I guess it stays as is :) --Geoff