You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/12/10 02:21:54 UTC
a new directive: PerlStartupFile?
As a followup to the discussed issue, we need to redefine the concept of:
"put those things in startup.pl"
we now need to say:
"put those things in post_config phase handler"
So users need to do:
PerlRequire "startup.pl"
startup.pl:
use Apache::ServerUtil ();
Apache->server->push_handlers(PerlPostConfigHandler =>
sub { require "somefile.pl" });
which is not so easy as to say:
"put those things in startup.pl"
if the path is not hardcoded or not in INC, for example to do it
relatively, one needs to write as much as:
use Apache::ServerUtil ();
use Apache::ServerRec ();
use Apache::Process ();
my $s = Apache->server;
my $pool = $s->process->pool;
my $path = Apache::ServerUtil::server_root_relative($pool, "conf");
$s->push_handlers(PerlPostConfigHandler => sub {
require "$path/post_config_startup.pl" });
So there is a possibility to introduce a new directive: PerlStartupFile
(feel free to suggest a better name) which will be:
PerlStartupFile "somefile.pl"
which will do:
use Apache::ServerUtil ();
Apache->server->push_handlers(PerlPostConfigHandler =>
sub { require "somefile.pl" });
internally. and this will eliminate the need for
PerlRequire "startup.pl"
if you don't want to load any config directives stuff.
after discussing this with gozer on irc we aren't sure this is a good
idea, as for most people using the old startup.pl concept will still work.
So your comments are welcome...
gozer and I think that we could add this directive later on, and just
document the above code as "best practice" for now.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: a new directive: PerlStartupFile?
Posted by Stas Bekman <st...@stason.org>.
Larry Leszczynski wrote:
> Hi Stas -
>
>
>>As a followup to the discussed issue, we need to redefine the concept of:
>>
>> "put those things in startup.pl"
>>
>>we now need to say:
>>
>> "put those things in post_config phase handler"
>
> [...]
>
>>So there is a possibility to introduce a new directive: PerlStartupFile
>>(feel free to suggest a better name) which will be:
>>
>>PerlStartupFile "somefile.pl"
>
> [...]
>
>>after discussing this with gozer on irc we aren't sure this is a good
>>idea, as for most people using the old startup.pl concept will still work.
>
>
> Leaving things as-is sounds like it might be asking for trouble, e.g.
> people not aware of the implications between config and post-config, or
> people still using "PerlRequire startup.pl" from their mp1 setup and it
> works ok by coincidence, and suddenly stops working (or fails in
> mysterious ways) when they add something that unknowingly breaks the rules
> about config vs. post-config phases.
>
> Maybe it would also help to introduce an alias for PerlRequire called
> something like PerlConfigFile, to make it more obvious it should only be
> used to modify config, and recommend that instead of using "PerlRequire
> startup.pl" people should do:
>
> PerlConfigFile "some-file.pl"
> PerlStartupFile "some-other-file.pl"
>
> Or maybe since there is already PerlPostConfigHandler, parallel that and
> use the name PerlPostConfigFile instead of PerlStartupFile?:
>
> PerlConfigFile "some-file.pl"
> PerlPostConfigFile "some-other-file.pl"
>
> (Don't know about that, maybe PerlStartupFile seems more intuitive about
> what you'd use it for...)
Thanks for the comments, Larry. But we need to put this issue on hold a
bit, since apparently loading from config phase (startup.pl) and
post_config phase is not exactly the same. So once we figure out why there
is a difference I'll be able to give you a more intelligent reply.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlConfigRequire & PerlPostConfigRequire ( was:
a new directive: PerlStartupFile? )
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>> After some talk about exactly what to call these directive, here is a
>> patch. It's late, so it doesn't include
>> docs or tests, but it should give a good idea of what's required to
>> get this working.
>>
>> PerlConfigRequire is basically just PerlRequire with an immediate perl
>> startup
>> PerlPostConfigRequire delays requiring the files up to the last
>> possible moment, before interpreters begin
>> to get cloned, at the begining of mp's post_config phase.
>>
>> Feedback most welcome!
>
> gozer++
>
> comments below
>
>> Index: src/modules/perl/mod_perl.c
>> ===================================================================
>> @@ -646,6 +665,11 @@
>> MP_dSCFG(s);
>> dTHXa(scfg->mip->parent->perl);
>> #endif
>> + + if (!modperl_post_config_require(s, pconf)) {
>> + exit(1);
>> + }
>
> shouldn't it return an error (code) here, rather than exit?
Not really, since it takes care of logging the problem internally, the only important
thing is to be able to propagate failure up and stop apache's startup.
> also I find modperl_post_config_require not very intuitive, but I can't
> think of anything better. I guess it's OK, since it's only local. may be
> modperl_post_config_require_apply. dunno.
Yeah, I had the same naming problem, modperl_post_config_require_apply is
only a slightly better name, IMO.
>> Index: src/modules/perl/modperl_config.c
>> ===================================================================
>> --- src/modules/perl/modperl_config.c (revision 111578)
>> +++ src/modules/perl/modperl_config.c (working copy)
>> @@ -155,6 +155,7 @@
>>
>> scfg->PerlModule = apr_array_make(p, 2, sizeof(char *));
>> scfg->PerlRequire = apr_array_make(p, 2, sizeof(char *));
>> + scfg->PerlPostConfigRequire = apr_array_make(p, 2, sizeof(char *));
s/sizeof(char *)/sizeof(modperl_require_file_t *)/
> probably 1 table entry should be enough here.
I was just following what seems to be a convention to go for 2.
>> Index: src/modules/perl/modperl_types.h
>> ===================================================================
>> --- src/modules/perl/modperl_types.h (revision 111578)
>> +++ src/modules/perl/modperl_types.h (working copy)
>> @@ -65,6 +65,11 @@
>> };
>>
>> typedef struct {
>> + const char *file;
>> + PerlInterpreter *perl; +} modperl_require_file_t;
>
>
> shouldn't *perl be ifdef'ed by
>
> #ifdef USE_ITHREADS
> PerlInterpreter *perl;
> #endif
>
> You don't have aTHX under non-threaded perl.
>
> Same of course goes to the population of this variable and its usage
> (see APR__Pool.h for a similar case).
>
>> Index: t/conf/post_config_startup.pl
>> ===================================================================
>> --- t/conf/post_config_startup.pl (revision 111578)
>> +++ t/conf/post_config_startup.pl (working copy)
>> @@ -148,3 +148,5 @@
>> }
>>
>> 1;
>> +
>> +die "blargh";
>
> what's this die for?
That's the kind of leftover code that gets into patches submitted past midnight ;-)
>> Index: t/conf/extra.conf.in
>> ===================================================================
>> --- t/conf/extra.conf.in (revision 111578)
>> +++ t/conf/extra.conf.in (working copy)
>> @@ -1,6 +1,8 @@
>> # needed to test $r->psignature
>> ServerSignature On
>>
>> +PerlPostConfigRequire @ServerRoot@/conf/post_config_startup.pl
>> +
>> # The following tests require more than one interpreter during the
>> # same request:
>> #
>> Index: todo/release
>
> Also we discussed that we need to add a similar PerlPostConfigRequire
> for t/vhost and add a test similar to t/hooks/TestHooks/startup.pm and
> modperl_extra.pl:test_hooks_startup();
Yup, a revised patch including this will make it's way to the mailing-list.
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: [Patch mp2] PerlConfigRequire & PerlPostConfigRequire ( was:
a new directive: PerlStartupFile? )
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> After some talk about exactly what to call these directive, here is a
> patch. It's late, so it doesn't include
> docs or tests, but it should give a good idea of what's required to get
> this working.
>
> PerlConfigRequire is basically just PerlRequire with an immediate perl
> startup
> PerlPostConfigRequire delays requiring the files up to the last possible
> moment, before interpreters begin
> to get cloned, at the begining of mp's post_config phase.
>
> Feedback most welcome!
gozer++
comments below
> Index: src/modules/perl/mod_perl.c
> ===================================================================
> @@ -646,6 +665,11 @@
> MP_dSCFG(s);
> dTHXa(scfg->mip->parent->perl);
> #endif
> +
> + if (!modperl_post_config_require(s, pconf)) {
> + exit(1);
> + }
shouldn't it return an error (code) here, rather than exit?
also I find modperl_post_config_require not very intuitive, but I can't
think of anything better. I guess it's OK, since it's only local. may be
modperl_post_config_require_apply. dunno.
> Index: src/modules/perl/modperl_config.c
> ===================================================================
> --- src/modules/perl/modperl_config.c (revision 111578)
> +++ src/modules/perl/modperl_config.c (working copy)
> @@ -155,6 +155,7 @@
>
> scfg->PerlModule = apr_array_make(p, 2, sizeof(char *));
> scfg->PerlRequire = apr_array_make(p, 2, sizeof(char *));
> + scfg->PerlPostConfigRequire = apr_array_make(p, 2, sizeof(char *));
probably 1 table entry should be enough here.
> Index: src/modules/perl/modperl_types.h
> ===================================================================
> --- src/modules/perl/modperl_types.h (revision 111578)
> +++ src/modules/perl/modperl_types.h (working copy)
> @@ -65,6 +65,11 @@
> };
>
> typedef struct {
> + const char *file;
> + PerlInterpreter *perl;
> +} modperl_require_file_t;
shouldn't *perl be ifdef'ed by
#ifdef USE_ITHREADS
PerlInterpreter *perl;
#endif
You don't have aTHX under non-threaded perl.
Same of course goes to the population of this variable and its usage (see
APR__Pool.h for a similar case).
> Index: t/conf/post_config_startup.pl
> ===================================================================
> --- t/conf/post_config_startup.pl (revision 111578)
> +++ t/conf/post_config_startup.pl (working copy)
> @@ -148,3 +148,5 @@
> }
>
> 1;
> +
> +die "blargh";
what's this die for?
> Index: t/conf/extra.conf.in
> ===================================================================
> --- t/conf/extra.conf.in (revision 111578)
> +++ t/conf/extra.conf.in (working copy)
> @@ -1,6 +1,8 @@
> # needed to test $r->psignature
> ServerSignature On
>
> +PerlPostConfigRequire @ServerRoot@/conf/post_config_startup.pl
> +
> # The following tests require more than one interpreter during the
> # same request:
> #
> Index: todo/release
Also we discussed that we need to add a similar PerlPostConfigRequire for
t/vhost and add a test similar to t/hooks/TestHooks/startup.pm and
modperl_extra.pl:test_hooks_startup();
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
[Patch mp2] PerlConfigRequire & PerlPostConfigRequire ( was: a new
directive: PerlStartupFile? )
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> [...]
> PerlRequire stays where it is.
>
> PerlConfigFile = StartPerl + PerlRequire (ensures to be run at config
> phase)
>
> Same as PerlLoadModule vs. PerlModule.
After some talk about exactly what to call these directive, here is a
patch. It's late, so it doesn't include
docs or tests, but it should give a good idea of what's required to get
this working.
PerlConfigRequire is basically just PerlRequire with an immediate perl
startup
PerlPostConfigRequire delays requiring the files up to the last possible
moment, before interpreters begin
to get cloned, at the begining of mp's post_config phase.
Feedback most welcome!
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: a new directive: PerlStartupFile?
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> Stas Bekman wrote:
>
>> OK, the post_config story is now resolved, we can get back to this
>> discussion.
>>
>> Larry Leszczynski wrote:
>>
>>> Hi Stas -
>>>
>>>> As a followup to the discussed issue, we need to redefine the
>>>> concept of:
>>>>
>>>> "put those things in startup.pl"
>>>>
>>>> we now need to say:
>>>>
>>>> "put those things in post_config phase handler"
>>>
>>>
>>> [...]
>>>
>>>> So there is a possibility to introduce a new directive: PerlStartupFile
>>>> (feel free to suggest a better name) which will be:
>>>>
>>>> PerlStartupFile "somefile.pl"
>>>
>>>
>>> [...]
>>>
>>>> after discussing this with gozer on irc we aren't sure this is a good
>>>> idea, as for most people using the old startup.pl concept will still
>>>> work.
>>>
>>>
>>> Leaving things as-is sounds like it might be asking for trouble, e.g.
>>> people not aware of the implications between config and post-config, or
>>> people still using "PerlRequire startup.pl" from their mp1 setup and it
>>> works ok by coincidence, and suddenly stops working (or fails in
>>> mysterious ways) when they add something that unknowingly breaks the
>>> rules
>>> about config vs. post-config phases.
>>
>>
>> Everything will work just the same either way, it's just that STDERR
>> is closed during the config phase's 2nd pass (when Apache restarts
>> itself).
>
>
> And also, most people will not be doing things that are 'forbidden' in
> there,
> like running different code on each pass, so it should be harmless in most
> cases.
>
>>> Maybe it would also help to introduce an alias for PerlRequire called
>>> something like PerlConfigFile, to make it more obvious it should only be
>>> used to modify config, and recommend that instead of using "PerlRequire
>>> startup.pl" people should do:
>>>
>>> PerlConfigFile "some-file.pl"
>>> PerlStartupFile "some-other-file.pl"
>>>
>>> Or maybe since there is already PerlPostConfigHandler, parallel that and
>>> use the name PerlPostConfigFile instead of PerlStartupFile?:
>>>
>>> PerlConfigFile "some-file.pl"
>>> PerlPostConfigFile "some-other-file.pl"
>
>
> I like the consistency in this case.
>
>>> (Don't know about that, maybe PerlStartupFile seems more intuitive about
>>> what you'd use it for...)
>>
>>
>> Yup, those are the two ideas philippe and I have discussed, we are
>> just not sure it's a very good idea to introduce a new directive which
>> does the same thing as PerlRequire. But in fact I like the idea. Since
>> PerlRequire normally is not run during the config phase (unless
>> something forces perl startup early, e.g. perlloadmodule or <perl>
>> section). So currently:
>>
>> PerlRequire "startup.pl"
>>
>> doesn't necessarily runs during the config phase.
>>
>> by making PerlConfigFile forcing perl startup early, it'll make more
>> sense, since it'll ensure to be run during the config phase.
>
>
> Yes. less magic and more consistency. I think it does make sense.
>
>> and then of course PerlPostConfigFile which does the wrapping to push
>> the handler is a nice sugar syntax.
>>
>> So I'm +1 for:
>>
>> PerlConfigFile "some-file.pl"
>> PerlPostConfigFile "some-other-file.pl"
>
>
> I think it's a good choice as well, but what about PerlRequire itself ?
> Just an
> alias to PerlConfigFile ?
PerlRequire stays where it is.
PerlConfigFile = StartPerl + PerlRequire (ensures to be run at config phase)
Same as PerlLoadModule vs. PerlModule.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: a new directive: PerlStartupFile?
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> OK, the post_config story is now resolved, we can get back to this
> discussion.
>
> Larry Leszczynski wrote:
>
>> Hi Stas -
>>
>>> As a followup to the discussed issue, we need to redefine the concept
>>> of:
>>>
>>> "put those things in startup.pl"
>>>
>>> we now need to say:
>>>
>>> "put those things in post_config phase handler"
>>
>> [...]
>>
>>> So there is a possibility to introduce a new directive: PerlStartupFile
>>> (feel free to suggest a better name) which will be:
>>>
>>> PerlStartupFile "somefile.pl"
>>
>> [...]
>>
>>> after discussing this with gozer on irc we aren't sure this is a good
>>> idea, as for most people using the old startup.pl concept will still
>>> work.
>>
>> Leaving things as-is sounds like it might be asking for trouble, e.g.
>> people not aware of the implications between config and post-config, or
>> people still using "PerlRequire startup.pl" from their mp1 setup and it
>> works ok by coincidence, and suddenly stops working (or fails in
>> mysterious ways) when they add something that unknowingly breaks the
>> rules
>> about config vs. post-config phases.
>
> Everything will work just the same either way, it's just that STDERR is
> closed during the config phase's 2nd pass (when Apache restarts itself).
And also, most people will not be doing things that are 'forbidden' in there,
like running different code on each pass, so it should be harmless in most
cases.
>> Maybe it would also help to introduce an alias for PerlRequire called
>> something like PerlConfigFile, to make it more obvious it should only be
>> used to modify config, and recommend that instead of using "PerlRequire
>> startup.pl" people should do:
>>
>> PerlConfigFile "some-file.pl"
>> PerlStartupFile "some-other-file.pl"
>>
>> Or maybe since there is already PerlPostConfigHandler, parallel that and
>> use the name PerlPostConfigFile instead of PerlStartupFile?:
>>
>> PerlConfigFile "some-file.pl"
>> PerlPostConfigFile "some-other-file.pl"
I like the consistency in this case.
>> (Don't know about that, maybe PerlStartupFile seems more intuitive about
>> what you'd use it for...)
>
> Yup, those are the two ideas philippe and I have discussed, we are just
> not sure it's a very good idea to introduce a new directive which does
> the same thing as PerlRequire. But in fact I like the idea. Since
> PerlRequire normally is not run during the config phase (unless
> something forces perl startup early, e.g. perlloadmodule or <perl>
> section). So currently:
>
> PerlRequire "startup.pl"
>
> doesn't necessarily runs during the config phase.
>
> by making PerlConfigFile forcing perl startup early, it'll make more
> sense, since it'll ensure to be run during the config phase.
Yes. less magic and more consistency. I think it does make sense.
> and then of course PerlPostConfigFile which does the wrapping to push
> the handler is a nice sugar syntax.
>
> So I'm +1 for:
>
> PerlConfigFile "some-file.pl"
> PerlPostConfigFile "some-other-file.pl"
I think it's a good choice as well, but what about PerlRequire itself ? Just an
alias to PerlConfigFile ?
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: a new directive: PerlStartupFile?
Posted by Stas Bekman <st...@stason.org>.
OK, the post_config story is now resolved, we can get back to this discussion.
Larry Leszczynski wrote:
> Hi Stas -
>
>
>>As a followup to the discussed issue, we need to redefine the concept of:
>>
>> "put those things in startup.pl"
>>
>>we now need to say:
>>
>> "put those things in post_config phase handler"
>
> [...]
>
>>So there is a possibility to introduce a new directive: PerlStartupFile
>>(feel free to suggest a better name) which will be:
>>
>>PerlStartupFile "somefile.pl"
>
> [...]
>
>>after discussing this with gozer on irc we aren't sure this is a good
>>idea, as for most people using the old startup.pl concept will still work.
>
>
> Leaving things as-is sounds like it might be asking for trouble, e.g.
> people not aware of the implications between config and post-config, or
> people still using "PerlRequire startup.pl" from their mp1 setup and it
> works ok by coincidence, and suddenly stops working (or fails in
> mysterious ways) when they add something that unknowingly breaks the rules
> about config vs. post-config phases.
Everything will work just the same either way, it's just that STDERR is
closed during the config phase's 2nd pass (when Apache restarts itself).
> Maybe it would also help to introduce an alias for PerlRequire called
> something like PerlConfigFile, to make it more obvious it should only be
> used to modify config, and recommend that instead of using "PerlRequire
> startup.pl" people should do:
>
> PerlConfigFile "some-file.pl"
> PerlStartupFile "some-other-file.pl"
>
> Or maybe since there is already PerlPostConfigHandler, parallel that and
> use the name PerlPostConfigFile instead of PerlStartupFile?:
>
> PerlConfigFile "some-file.pl"
> PerlPostConfigFile "some-other-file.pl"
>
> (Don't know about that, maybe PerlStartupFile seems more intuitive about
> what you'd use it for...)
Yup, those are the two ideas philippe and I have discussed, we are just
not sure it's a very good idea to introduce a new directive which does the
same thing as PerlRequire. But in fact I like the idea. Since PerlRequire
normally is not run during the config phase (unless something forces perl
startup early, e.g. perlloadmodule or <perl> section). So currently:
PerlRequire "startup.pl"
doesn't necessarily runs during the config phase.
by making PerlConfigFile forcing perl startup early, it'll make more
sense, since it'll ensure to be run during the config phase.
and then of course PerlPostConfigFile which does the wrapping to push the
handler is a nice sugar syntax.
So I'm +1 for:
PerlConfigFile "some-file.pl"
PerlPostConfigFile "some-other-file.pl"
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: a new directive: PerlStartupFile?
Posted by Larry Leszczynski <la...@emailplus.org>.
Hi Stas -
> As a followup to the discussed issue, we need to redefine the concept of:
>
> "put those things in startup.pl"
>
> we now need to say:
>
> "put those things in post_config phase handler"
[...]
> So there is a possibility to introduce a new directive: PerlStartupFile
> (feel free to suggest a better name) which will be:
>
> PerlStartupFile "somefile.pl"
[...]
> after discussing this with gozer on irc we aren't sure this is a good
> idea, as for most people using the old startup.pl concept will still work.
Leaving things as-is sounds like it might be asking for trouble, e.g.
people not aware of the implications between config and post-config, or
people still using "PerlRequire startup.pl" from their mp1 setup and it
works ok by coincidence, and suddenly stops working (or fails in
mysterious ways) when they add something that unknowingly breaks the rules
about config vs. post-config phases.
Maybe it would also help to introduce an alias for PerlRequire called
something like PerlConfigFile, to make it more obvious it should only be
used to modify config, and recommend that instead of using "PerlRequire
startup.pl" people should do:
PerlConfigFile "some-file.pl"
PerlStartupFile "some-other-file.pl"
Or maybe since there is already PerlPostConfigHandler, parallel that and
use the name PerlPostConfigFile instead of PerlStartupFile?:
PerlConfigFile "some-file.pl"
PerlPostConfigFile "some-other-file.pl"
(Don't know about that, maybe PerlStartupFile seems more intuitive about
what you'd use it for...)
Larry Leszczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org