On Tue, 31 Jul 2001, Philip Mak wrote:
> On Tue, 31 Jul 2001, Kyle Oppenheim wrote:
>
> > Apache::Reload works by performing a stat on every file in %INC and calling
> > require for all the files that changed. It's quite possible that some of
> > the files in %INC are using relative paths (often '.' is in @INC). So, Perl
> > was able to load the file originally because the initial 'use' or 'require'
> > was after Apache changed to your directory. However, when Apache::Reload
> > goes to look for the file, it can't find it because the current directory is
> > different (most likely the ServerRoot).
>
> I've ran into this problem with Apache::Reload a couple of times myself.
>
> Isn't there a way that Apache::Reload can be made to work transparently
> (in the spirit of making programs "Do The Right Thing (tm)")? Perhaps by
> overloading the "use" and "require" functions to convert pathnames to be
> fully qualified before inserting them in %INC?
This is a good idea, though you cannot do that unless you are running
under 5.6 or some earlier Perl which supports the notion of GLOBAL::CORE::
namespace (which can be a bad thing to do anyway). Or write some XS code
:)
Extending your @INC is the simplest solution. The docs should be updated
and you will be all set.
> (I think this would also help with same-named mod_perl scripts from
> different VirtualHosts in the same instance of Apache interfering with
> each others' execution?)
Not really. You have 1:1 mapping in %INC. How exactly do you suggest it to
work?
It'll be all clean in mod_perl 2.0, where every vh will have its own pool
of interpreters if wanted, with a private copy of %INC.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
