develooper Front page | perl.perl5.porters | Postings from November 2004

Re: [PATCH] Re: getting on a diet

Thread Previous | Thread Next
Craig A. Berry
November 30, 2004 21:02
Re: [PATCH] Re: getting on a diet
Message ID:
In article <>, 

> Craig Berry <> 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, 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's AUTOLOAD method work
> :a little harder to find in the same place it found 
> 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 

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About