On Saturday, November 27, 2004, at 11:09PM, Craig A. Berry <[EMAIL PROTECTED]>
wrote:
> When it gets to building the utilities, it fails like so:
>
>MCR Sys$Disk:[]miniperl.exe "-I[.lib]" [.UTILS]PERLDOC.PL
>Can't locate Config_heavy.pl in @INC (@INC contains: lib/VMS_AXP lib
>perl_root:[lib.VMS_AXP.5_9_2] perl_root:[lib] perl_root:[lib.si
>te_perl.VMS_AXP] perl_root:[lib.site_perl] /perl_root/lib/site_perl .) at
>lib/Config.pm line 62.
>Extracting "perldoc.com" (with variable substitutions)
>%RMS-E-FNF, file not found
>
>Since Config_heavy.pl does exist and is located in the same places
>that Config.pm is located, I don't understand why it can find the one
>but not the other. I'll keep looking.
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? Otherwise it seems
we're breaking the promise made by a successful C<use Config;> that we've
loaded the module and can use what it's exporting whenever we want.
