Peter Prymmer wrote:
> Chuck Lane wrote:
>> A patch for the glob-basic test was posted here on 17 Mar.
> Apparently it was missed when assembling 5.6.0 unfortunately.
The fix to the test logic (my earlier thinko, I'm afraid) was ready
to go, but the later fix involving whether "NOCASE" options should be
applied even when overriding defaults needed more discussion.
There was bit more discussion, but I don't recall a consensus being reached.
>>...on the subject of piping changes and using PERL_ROOT:
> It is my preference that we maintain the insensitivity to PERL_ROOT &&
> PERLSHR if possible. If not possible then I can go with putting an @perl_setup
> earlier in the descrip.mms although we'd have to take into account the fact
> that the PERLSRC tree may differ from the intended PERL_ROOT installation
> tree as dictated by the combination of descrip.mms and the installperl script
> (in which case putting a DEFINE PERL_ROOT rather than a @perl_setup may be
> the better way to go - if necessary).
The DESCRIP.MMS code I posted does the following:
define PERL_ROOT pointing to main Perl distrib. directory if not already defined
copy VMSPIPE.COM from the [.vms] directory up to the main Perl distrib. directory
copy VMSPIPE.COM from main Perl distrib. dir to installation dir
I put the "define PERL_ROOT" in a .FIRST section, but I can tell that
some changes will be needed; an existing PERL_ROOT def'n probably won't be
useful during the new build for example...I'll update and rerelease
It was the build/install bits that were the roughest and needed the most
feedback, BTW.
> I am not necessarily opposed to hard coded path names, although I do know
> that they can be problematic especially if one has to take into account
> the difference between a PERLSRC tree and an installed PERL_ROOT tree.
See above; there's a VMSPIPE.COM copied to both, so PERL_ROOT pointing to
either is okay. And while we do copy PERL.EXE to t/PERL. for testing,
it won't get very far unless it has a pointer to PERLSHR.EXE. Because
of having the shareable image, it seems (to me) futile to try and avoid
use of logicals during build and testing. Does it really help?
Avoiding dependance on having the logicals set up properly *before*
invoking "MMK test", sure... but MMK should be able to set up some
logicals that the build and test code depend on.
BTW, I don't much like hardcoded pointers since every and then I'll have
to move a directory around...that's actually a beef I have with the current
PERL_SETUP: I think it should define PERLSHR, PERL_ROOT etc. based on
directory that PERL_SETUP.COM is located in....move the whole tree and the
PERL_SETUP still works. (whether Config.pm still does is another can of worms)
--
Drexel University \V --Chuck Lane
----------------->--------*------------<[EMAIL PROTECTED]
(215) 895-1545 / \ Particle Physics [EMAIL PROTECTED]
FAX: (215) 895-5934 /~~~~~~~~~~~ [EMAIL PROTECTED]
