In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> Craig Berry <[EMAIL PROTECTED]> wrote:
> :OK, what's happening is the utility generator scripts are doing the
> :equivalent of
> :
> :use Config;
> :chdir 'somewhere_else';
> :$x = $Config{flirble};
> :
> :The fetch of 'flirble' fails because it's depending on a relative path in
> :@INC, and when it goes to require Config_heavy.pl, that relative path is
> :no good anymore because of the chdir. I can easily patch up the VMS build
> :to put ../lib as well as ./lib in @INC, but I wonder if that's the right
> :way to go. Would it be kosher to make Config.pm's AUTOLOAD method work
> :a little harder to find Config_heavy.pl in the same place it found
> :Config.pm?
>
> I think it would set a bad precedent to have a core module ignoring
> changes affecting @INC.
It would only ignore run-time changes to @INC or run-time changes to
the current working directory that render relative paths in the
existing @INC useless. Camel 3 p. 300 says, "Since C<use> loads
modules at compile time, any modifications to C<@INC> need to occur at
compile time as well." Since Config has moved part of its load process
from compile time to run time, it seems to me it's responsible for
making sure it finds its own private pieces at run time as if it had
all happened at compile time.
> Maybe it would be possible to replace ./lib
> with its fully-qualified equivalent? That has the benefit of expressing
> the intent: to add *this* lib directory to @INC.
Yes, we could do that, or we could just do what the Unix build does and
sprinkle -I../lib everywhere. I have a patch in progress to do the
latter.
