Re: [PATCH] Re: getting Config.pm on a diet
Craig A. Berry [EMAIL PROTECTED] wrote: :In article [EMAIL PROTECTED], [EMAIL PROTECTED] :wrote: : 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. Yes, but if you've put a relative directory in @INC it should stay relative when the CWD changes. Note that there may be good reasons for doing this, for example in situations where you are substantially changing the environment in which the program runs, such as chroot(), umount() or simply unlink(). : Camel 3 p. 300 says, Since Cuse loads :modules at compile time, any modifications to C@INC need to occur at :compile time as well. The Camel may be misleading: there may be many compile times during the running of a program. : 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. In general, I would not expect any onus on a module writer to ensure that all subsidiary modules it needs be resolved when their module is first compiled. It should be assumed perfectly reasonable to write any module to defer loading of subsidiary modules to the point they are needed. Therefore I conclude that it is in general unsafe to put relative paths in @INC except where you specifically know it is appropriate, either because you know the script will not chdir, or because you want the paths to stay relative even when it does. : 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. By the above reasoning, we should rather be fixing the Unix build to avoid both ./lib and ../lib. Whether that is practical to achieve at this time is a separate question, of course. However I suspect that such a change would be a large enough perturbation of the build system that it would be unlikely to go into the maintenance branch, so I guess it is worth continuing with your current patch in any case. Hugo
Re: [PATCH] Re: getting Config.pm on a diet
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 Cuse 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.
Re: [PATCH] Re: getting Config.pm on a diet
Note: I think I only get mail on the [EMAIL PROTECTED] list. Nicholas Clark wrote: On Mon, Nov 29, 2004 at 01:58:52PM -0600, Craig Berry wrote: I'm not sure. I was trying to keep Config's AUTOLOAD as simple as possible. Then again, using %INC shouldn't be that hard. For the Unix Makefile I hit the same problem (with the POD scripts) and the solution I found was to change the -I on the command line from a relative to an absolute path. Is that viable with the VMS MMS file? Or have I missed some VMS specific subtilty? A VMS specific method would be to have a logical name that equated to a search list. $define foobar foo:[dir1],bar:[dir2] You can have quite a few directories on the list, and they would show up in UNIX syntax as all being in the same directory: foobar/x.h My preference in doing VMS builds of application is to use the search list feature of logical names to isolate the source from the resulting binaries and intermediate files. For example: Dist_root:[*...] is a source directory tree that the build procedure does not have privilege to modify. local_root:[*...] is the directory with locally modified source files for testing patches, etc. DEFINE BUILD_ROOT local_root:,dist_root: Set default BUILD_ROOT:[00] ! Or other base directory. Now VMS will automatically look in the local_root: directory tree first for a file, and if it is not found, will look in dist_root: directory tree. New files being created will be put in the LOCAL_ROOT: tree. This does not work if the build procedure is expecting to actually modify files from the original distribution in place. Perl at the last time I attempted a build on VMS could not use such a search list. FYI: It looks like building SAMBA Version 4 on VMS will require using PERL to do the configuration phase. -John [EMAIL PROTECTED] Personal Opinion Only
Re: [PATCH] Re: getting Config.pm on a diet
At 9:57 PM + 11/27/04, Nicholas Clark wrote: On Sat, Nov 27, 2004 at 03:31:17PM -0600, Craig A. Berry wrote: \ The editing looks fine. It appears that we also need the attached patch to get Config_heavy.pl put in the right place at the right time. Oops. I missed one then. Sorry about that, and thanks for the quick patch. (Applied as 23557) Great, thanks. Unfortunately we're not quite done yet. It seemed to work before because I had a PERL5LIB definition that compensated for the following problem. 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. Discussion of missing config symbols snipped. All these symbols are defined on Unix, but quite possibly empty strings. I'm not sure if it's more correct for me to modify configpm to cope with then being undefined, or for the VMS configure system to be consistent with Unix and set the first 4 to empty strings, and the 5th to the same as libs. It should be easy enough to add those to configure.com -- I'll look into it. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
