Charles Lane wrote:
> I'm not sure why we're trying to avoid PERL_ROOT during testing; it's
> a cause of a lot of the grief we're having now. Perhaps it's some
> unix thing, since those poor guys don't have logicals to help them out.
> Sort of like programming without pointers, doncha know :)
A lot of what gets done with logical names can be covered with
links or symlinks on Unix, neither of which is actually used much
in the build, test, and install of perl (save for the link that points
from /usr/local/bin/perl5.6.0 to /usr/local/bin/perl ). Of course
symlinks don't work as search lists :-)
> It seems much more natural, if we're testing code, that we'd want
> to have the code in an environment as close to "normal" as possible.
> Meaning that PERL_ROOT would be defined and pointing to all the
> module goodies put in place by the build.
I agree with this in principle. However we'd have to face up to the fact
that to really test an installed perl one would need to run the installperl
script before running the test since the installperl script could decide
to rename or relocate things in ways the Makefile or descrip.mms file did not
foresee. Note too that installperl does have some C<if ($^O eq 'VMS')> code
in it already.
On the other hand I'd like to run a `make test` (or `make check` for GNU wares)
before I run a `make install`. Hence the coverage of any such test suite is
fundamentally suspect. But I can run `mms install` then re-run the
[.t]test.com with the installed perl thereby uncovering any installation
layout dependent failures. Hence the test suite needs relocatability
which is why it is littered with C<-I../foo> type code.
One thing I like about the way perl builds and installs on VMS is that it
does not leave your environment unusable (unlike say the DELETE/SYMBOL/ALL
that VMSINSTAL.COM forces down your login process's throat). I guess the
"tread lightly on pre-extant PERL_ROOT's" is a part of that, though we
may need to have something like configure.com issue some kind of warning
about that or a PERLSHR logical.
Peter Prymmer
