perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: removing PerlLoadModule directive handler requirement
Date Thu, 22 May 2003 04:02:16 GMT

> Don't you
> think it's a bad design, if all you want is to trigger the perl startup 
> early?

no :)

because that's not all I want to do.  what I want is to have my code run 
during the config phase, and that happens to require that Perl be running. 
see, it's not early if I require it - it's only early if it's started for no 
reason :)

> If perl is not started during the config phase, all directives
> like PerlModule and PerlRequire are postponed till after the config 
> phase. If you wish to force those to run immediately during the config 
> phase, you can turn on the early perl startup using the PerlStartNow 
> directive.

the issue is that some modules require activity during startup/config, and 
thus require Perl to be running.  adding PerlStartNow means that modules 
cannot rely on only themselves to work - they require even more outside 
intervention in the form of additional directives to even load properly. yucko.

> now we just need to implement this simple directive.

I don't see the reason for this - you can always just insert a no-op within 
<Perl>.  the effect I want is the ability for module loading to be more DWIMmy.

> BTW, as I think about it, since the startup file execution is normally 
> postponed, it's impossible to change the config via $s->add_config. So 
> this is another case where perl must be started early.
> Alternatively we can take a more intuitive direction (mp1-like): always 
> start perl as soon as is loaded. Have a directive that will 
> try to postpone the startup of perl.

I don't think we need that either.  it does make some sense to delay perl 
until it's needed.  it's just that for some things it's needed at config.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message