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 13:28:09 GMT

 >> not exactly.  I think it's fine in most cases to have PerlModule behave
 >> as it does now.  it's in the exceptional cases that the problem
 >> resides.
 > Actually it's not fine now. Consider:

 > PerlRequire /path/to/
 > As the current implementation goes we have a problem, because it won't
 > work unless something (<Perl> or PerlLoadModule) has triggered a perl
 > startup and the file was actually required during the config
 > phase.

oops :)

 > So what I'm saying that your issue is not the only one that requires an
 > early perl startup. So may be the problem is more global and solving it
 > will automatically resolve your issue, without any heavy patching.

as I had originally though about it, I figured the issue would only reside
with modules.  but, as you pointed out, config changes in will 
have issues too.  hmph.

personally, I can't see many people using add_config from a - if 
they can add a they can add the config themselves (except for 
maybe the tests :).  more typically, I would expect add_config() to be 
called from modules as to add config settings silently.  Apache::WinBitHack 
is a good example - it overrides XBitHack but (in mp1) still needs to add a 
PerlFixupHandler to function properly.  in mp2 it would just override 
XBitHack and silently add the fixup handler via add_config().  doug's 
illustration of using it to add require directives I suspect will also be a 
common use.

are there other config situations other than add_config() that you can think 
of?  I still think it's valid to delay interpreter start and have PerlModule 
behave as it does now (provided we have an alternative :), but as the number 
of exceptional cases rise, it makes less and less sense.


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

View raw message