You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-cvs@httpd.apache.org by co...@apache.org on 2004/04/02 01:57:17 UTC
cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
coar 2004/04/01 15:57:17
Modified: perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestConfigParse.pm
Log:
add an '-httpd_conf_extra <filename>' option to allow
an *additional* server config file to be inherited as
well as the server's main one (or one specified with
-httpd_conf).
Reviewed by: stas
Revision Changes Path
1.217 +3 -2 httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm
Index: TestConfig.pm
===================================================================
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.216
retrieving revision 1.217
diff -u -u -r1.216 -r1.217
--- TestConfig.pm 1 Apr 2004 18:56:21 -0000 1.216
+++ TestConfig.pm 1 Apr 2004 23:57:17 -0000 1.217
@@ -72,6 +72,7 @@
apxs => 'location of apxs (default is from Apache::BuildConfig)',
startup_timeout => 'seconds to wait for the server to start (default is 60)',
httpd_conf => 'inherit config from this file (default is apxs derived)',
+ httpd_conf_extra=> 'inherit additional config from this file',
maxclients => 'maximum number of concurrent clients (default is 1)',
perlpod => 'location of perl pod documents (for testing downloads)',
proxyssl_url => 'url for testing ProxyPass / https (default is localhost)',
@@ -84,8 +85,8 @@
my %filepath_conf_opts = map { $_ => 1 }
qw(top_dir t_dir t_conf t_logs t_conf_file src_dir serverroot
- documentroot bindir sbindir httpd apxs httpd_conf perlpod sslca
- libmodperl);
+ documentroot bindir sbindir httpd apxs httpd_conf httpd_conf_extra
+ perlpod sslca libmodperl);
sub conf_opt_is_a_filepath {
my $opt = shift;
1.44 +13 -2 httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm
Index: TestConfigParse.pm
===================================================================
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -u -r1.43 -r1.44
--- TestConfigParse.pm 4 Mar 2004 05:51:31 -0000 1.43
+++ TestConfigParse.pm 1 Apr 2004 23:57:17 -0000 1.44
@@ -302,6 +302,7 @@
catfile $self->{httpd_basedir}, 'htdocs';
my $file = $self->{vars}->{httpd_conf};
+ my $extra_file = $self->{vars}->{httpd_conf_extra};
unless ($file and -e $file) {
if (my $base = $self->{httpd_basedir}) {
@@ -313,7 +314,16 @@
}
}
- return unless $file;
+ unless ($extra_file and -e $extra_file) {
+ if ($extra_file and my $base = $self->{httpd_basedir}) {
+ my $default_conf = catfile qw(conf $extra_file);
+ $extra_file = catfile $base, $default_conf;
+ # SERVER_CONFIG_FILE might be an absolute path
+ $extra_file = $default_conf if !-e $extra_file and -e $default_conf;
+ }
+ }
+
+ return unless $file or $extra_file;
my $c = $self->{inherit_config};
@@ -324,7 +334,8 @@
}
}
- $self->inherit_config_file_or_directory($file);
+ $self->inherit_config_file_or_directory($file) if $file;
+ $self->inherit_config_file_or_directory($extra_file) if $extra_file;
#apply what we parsed
while (my($spec, $wanted) = each %wanted_config) {
Re: Apache test -- Perl-test-framework
Posted by Stas Bekman <st...@stason.org>.
Abhishek Khandelwal wrote:
> Is there a way to count the total number of tests when the perl-test
> suits are run.
> If all the tests passes, then in final report it specifies the total
> number of files and total number of tests run. But in case there are
> tests which fails, it publishes a report which looks like as follows:
>
> ------------------------------------------------------------------
> Failed Test Stat Wstat Total Fail Failed List of Failed
> -------------------------------------------------------------------------------
> modules/cgi.t 50 21 42.00% 14 16 24 26 28 30 32 34 36 38-
> 41 43-50
> modules/include.t 82 6 7.32% 11 27 39 41-42 65
> ssl/http.t 255 65280 2 4 200.00% 1-2
> ssl/proxy.t 169 2 1.18% 114 117
> 2 tests and 14 subtests skipped.
> !!! error running tests (please examine t/logs/error_log)
>
> ------------------------------------------------------------------
>
> Now I dont have any way to know how many total tests were run as the report only shows the results of failed tests.
>
> Does anyone know a way to do it. My guess is, I can somehow instrument Apache::Test or Apache::TestRequest etc to get the total count.
>
> Please help.
Abhishek, this report is printed by Test::Harness, not Apache-Test, i.e. it's
not under our control. Feel free
to contact the authors of Test::Harness at bug-test-harness <at> rt.cpan.org
and ask them to fix that. This part of the report is definitely missing, IMHO.
Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Apache test -- Perl-test-framework
Posted by Abhishek Khandelwal <ak...@spikesource.com>.
Is there a way to count the total number of tests when the perl-test
suits are run.
If all the tests passes, then in final report it specifies the total
number of files and total number of tests run. But in case there are
tests which fails, it publishes a report which looks like as follows:
------------------------------------------------------------------
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
modules/cgi.t 50 21 42.00% 14 16 24 26 28 30 32 34 36 38-
41 43-50
modules/include.t 82 6 7.32% 11 27 39 41-42 65
ssl/http.t 255 65280 2 4 200.00% 1-2
ssl/proxy.t 169 2 1.18% 114 117
2 tests and 14 subtests skipped.
!!! error running tests (please examine t/logs/error_log)
------------------------------------------------------------------
Now I dont have any way to know how many total tests were run as the report only shows the results of failed tests.
Does anyone know a way to do it. My guess is, I can somehow instrument Apache::Test or Apache::TestRequest etc to get the total count.
Please help.
Thanks,
Abhishek
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>By splicing you mean 'Include ken_extra.conf' from t/conf/httpd.conf?
>>Yes, but have_module() doesn't look it up in any of the conf files, it
>>looks it up from the config object $cfg->{modules} which get populate
>>with available modules when the config is generated, and it only scans
>>the inherited file, it doesn't scan any of the files in t/conf.
>
>
> no, what I meant was that ken_extra.conf (httpd.extra.conf.in ->
> httpd.extra.conf) would get appended to the currently generated httpd.conf,
> then _that_ result is what is scanned. but maybe it's not as simple to
> change the internal logic to accomodate that.
But we don't scan anything in t/conf/, besides replacing @vars@ and assigning
ports. You will have to change the logic to do that. Therefore inhereted
config is a perfect fit, since we do scan it for LoadModule directives.
>>>anyway I was just making a suggestion - it seems limiting to me not to
>>>have
>>>substitution in extra configuration files,
>>
>>
>>But that's exactly what Ken doesn't want. He wants to give his own file
>>which he has cooked already. This new option and your suggestion don't
>>contradict each other. and each has a merit for existence.
>
>
> I still don't see how the idea I'm proposing isn't sufficient, save that it
> would need to live within t/conf. that we could make it support variable
> substitution doesn't mean that it can't be 100% hard-coded.
It just won't work the way things are now. Again, what Ken needs is scanning
of LoadModule directives.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> By splicing you mean 'Include ken_extra.conf' from t/conf/httpd.conf?
> Yes, but have_module() doesn't look it up in any of the conf files, it
> looks it up from the config object $cfg->{modules} which get populate
> with available modules when the config is generated, and it only scans
> the inherited file, it doesn't scan any of the files in t/conf.
no, what I meant was that ken_extra.conf (httpd.extra.conf.in ->
httpd.extra.conf) would get appended to the currently generated httpd.conf,
then _that_ result is what is scanned. but maybe it's not as simple to
change the internal logic to accomodate that.
>> anyway I was just making a suggestion - it seems limiting to me not to
>> have
>> substitution in extra configuration files,
>
>
> But that's exactly what Ken doesn't want. He wants to give his own file
> which he has cooked already. This new option and your suggestion don't
> contradict each other. and each has a merit for existence.
I still don't see how the idea I'm proposing isn't sufficient, save that it
would need to live within t/conf. that we could make it support variable
substitution doesn't mean that it can't be 100% hard-coded.
>
>> 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
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
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.
By splicing you mean 'Include ken_extra.conf' from t/conf/httpd.conf? Yes, but
have_module() doesn't look it up in any of the conf files, it looks it up from
the config object $cfg->{modules} which get populate with available modules
when the config is generated, and it only scans the inherited file, it doesn't
scan any of the files in t/conf.
>>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,
But that's exactly what Ken doesn't want. He wants to give his own file which
he has cooked already. This new option and your suggestion don't contradict
each other. and each has a merit for existence.
> 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 :)
:)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> 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
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Stas Bekman <st...@stason.org>.
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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> coar@apache.org wrote:
>
>>coar 2004/04/01 15:57:17
>>
>> Modified: perl-framework/Apache-Test/lib/Apache TestConfig.pm
>> TestConfigParse.pm
>> Log:
>> add an '-httpd_conf_extra <filename>' option to allow
>> an *additional* server config file to be inherited as
>> well as the server's main one (or one specified with
>> -httpd_conf).
>
>
> ok, I guess you guys figured out how to do it :)
Looks like Ken's hair started to grow again, after he had it all lost over
this case :)
> anyway, if I can interject a few comments on the idea...
>
> we already have a few files that get magical treatment: extra.conf.in,
> extra.last.conf.in, modperl_startup.pl, etc. I think the way I would do it
> (from afar :) is to create yet another special case, maybe
> httpd.extra.conf.in or somesuch. advantages would be that it would follow
> the approach we've been using, it wouldn't require an extra runtime
> argument, and it could benefit from variable subsitution like all the other
> conf files.
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).
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.
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).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> coar@apache.org wrote:
>
>>coar 2004/04/01 15:57:17
>>
>> Modified: perl-framework/Apache-Test/lib/Apache TestConfig.pm
>> TestConfigParse.pm
>> Log:
>> add an '-httpd_conf_extra <filename>' option to allow
>> an *additional* server config file to be inherited as
>> well as the server's main one (or one specified with
>> -httpd_conf).
>
>
> ok, I guess you guys figured out how to do it :)
Looks like Ken's hair started to grow again, after he had it all lost over
this case :)
> anyway, if I can interject a few comments on the idea...
>
> we already have a few files that get magical treatment: extra.conf.in,
> extra.last.conf.in, modperl_startup.pl, etc. I think the way I would do it
> (from afar :) is to create yet another special case, maybe
> httpd.extra.conf.in or somesuch. advantages would be that it would follow
> the approach we've been using, it wouldn't require an extra runtime
> argument, and it could benefit from variable subsitution like all the other
> conf files.
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).
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.
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).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
coar@apache.org wrote:
> coar 2004/04/01 15:57:17
>
> Modified: perl-framework/Apache-Test/lib/Apache TestConfig.pm
> TestConfigParse.pm
> Log:
> add an '-httpd_conf_extra <filename>' option to allow
> an *additional* server config file to be inherited as
> well as the server's main one (or one specified with
> -httpd_conf).
ok, I guess you guys figured out how to do it :)
anyway, if I can interject a few comments on the idea...
we already have a few files that get magical treatment: extra.conf.in,
extra.last.conf.in, modperl_startup.pl, etc. I think the way I would do it
(from afar :) is to create yet another special case, maybe
httpd.extra.conf.in or somesuch. advantages would be that it would follow
the approach we've been using, it wouldn't require an extra runtime
argument, and it could benefit from variable subsitution like all the other
conf files.
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
TestConfig.pm TestConfigParse.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
coar@apache.org wrote:
> coar 2004/04/01 15:57:17
>
> Modified: perl-framework/Apache-Test/lib/Apache TestConfig.pm
> TestConfigParse.pm
> Log:
> add an '-httpd_conf_extra <filename>' option to allow
> an *additional* server config file to be inherited as
> well as the server's main one (or one specified with
> -httpd_conf).
ok, I guess you guys figured out how to do it :)
anyway, if I can interject a few comments on the idea...
we already have a few files that get magical treatment: extra.conf.in,
extra.last.conf.in, modperl_startup.pl, etc. I think the way I would do it
(from afar :) is to create yet another special case, maybe
httpd.extra.conf.in or somesuch. advantages would be that it would follow
the approach we've been using, it wouldn't require an extra runtime
argument, and it could benefit from variable subsitution like all the other
conf files.
--Geoff