Charles Lane <[EMAIL PROTECTED]> wrote:
|
| Charles Bailey [EMAIL PROTECTED] wrote:
| > What would you think of this alternative?
|
| > 1. Search @INC for file.
| > 2. On failure, try dirname($^X).
| > 3. Perhaps as last resort, try Perl_Root:[000000], though I'm
| > not sure this'll add much.
| > 4. Do the lookup from init_os_extras() (after -I and PERL5LIB
| > processing, but before the Perl code has a chance to fuss
| > with @INC or $^X.
|
| > Putative advantages: Incorporates normal Perl library mechanisms for
| > adapting to multiple versions/architecures, and provides a relatively
| > clean way to redirect. Putative disadvantages: Possible security concern
| > with -I, but if you allow users to specify -I when invoking sensitive scripts,
| > you may have a bigger problems (though script can say C<@INC = qw( ... )>);
| > possible inadvertent breakage through existence of an unrelated vmspipe.com
| > in -Id directory, as with any Perl library file.
|
| I'd like to note that if we start using Perl features (@INC, $^X) for
| things other than what they were intended, we are asking for trouble.
| Just my opinion.
. . . and a reasonable one, too. I'm not sure we're straying from the
intended purpose of @INC, though -- this is a type of library file, in
some ways like the (new) dependence of CORE::glob() on File::Glob() (under
certain non-VMS OSs) or -d on perldb.pl.
| 1. Perl installed, normal "user" execution:
| Since the search is in compiled code, why not just use ARCHLIB?
| Then we're not affected by -I and we still get architecure/versioning.
| This should work fine for an installed Perl.
|
| If we really need to search @INC, I'd say that we should do
| something like reverse the order of directories, drop the '.'
| directory and prepend an ARCHLIB. That way any -I directories are
| at the end of the list, and ARCHLIB (where VMSPIPE almost certainly is
| located) gets checked first.
The @INC approach does two things for us here:
- it handles any ARCHLIB/SITELIB/VENDORLIB silliness implicitly
- it lets us redirect the search (via -I) as needed in special cases
| And rather than having the performance hit of searching the directories
| each time Perl is run, it would be better just to cache a list of
| directories and search in the safe_popen routine.
That makes sense.
| 2. during MMK (build phase):
| assume PERL_ROOT "not useful" (not defined, old version)
| @INC search will fail, but
One of these has to work, else the various invocations of miniperl
during the build (e.g. MakeMaker) would fail. It's generally (should
always be) the latter via appropriate -Is.
| 3. during MMK TEST:
| assume PERL_ROOT "not useful".
|
| So all the directories in @INC that are based on PERL_ROOT are
| unusable for finding VMSPIPE.
Right -- we'd have to rely on -I again.
| During MMK TEST, we copy PERL.EXE to [.T]PERL., so dirname($^X)
| won't help us much unless we also copy VMSPIPE.COM to [.T]
| (with unknown effect on test scripts that use that directory
| as part of their testing schemes).
Good point -- what the back of my brain intended, I think, was
dirname($ENV{PERLSHR}) || 'SYS$SHARE:'.
| As I mentioned in a previous message, I don't think we can count
| on test scripts that spawn subprocesses passing an appropriate
| -I flag to subprocesses that aren't using modules...and the -I
| directories won't be the ARCHLIB directory that we really need.
Definitely a potential problem, though I don't know whether it's an
actual one; if necessary, the test driver could pass along -Is.
| 4. During MMK INSTALL:
| PERL_ROOT is set to installation location
| we may or may not have VMSPIPE findable via @INC, depending on
| when VMSPIPE is copied to its new location.
| $^X should still work though.
This is a tricky time overall, since one wants Perl_Root to point to
the installed location, but wants access to the library for various
modules. -I seems the most natural option.
While I do like the -I option (surprise!), I'm not strongly opposed
to using a Perl_Root-based version/arch-specific location. I would
really like to avoid adding code to the core that's useful only at
build time, though (or at least restrict it to miniperl, but that's
a tough one at the moment).
Regards,
Charles Bailey [EMAIL PROTECTED]
