John Peacock wrote:
!In my own defense, I normally build/test Perl in my home directory, using
a
!rooted logical. That seemed to be causing problems, so I just tried to do
the
!build in the future home of Perl, which my user doesn't ordinarily have
rights
!to, hence the use of 'set proc' in the first place.
Can you tell us more about the problems caused when using a
rooted logical? That not only should work but actually is
recommended building practice (applicable mainly to ODS-2 volumes
on VMS versions prior to V7.1) as mentioned in README.vms.
I have been trying to weed out trouble with building
from rooted logicals of late and would like to know more
about what you saw. (Most of the trouble related to
File::Spec::abs2rel() and should be fixed in [EMAIL PROTECTED]).
One thing that I have noted specifically with the [EMAIL PROTECTED]
kits is a craziness with @INC for finding Test::More whilst
attempting to run some regression tests outside of C<MMK test>.
I wrote this DCL script:
$ say := write sys$output
$ say "perl lib/ExtUtils/t/00compile.t" ! ............ok
$ perl lib/ExtUtils/t/00compile.t ! ............ok
$ say "perl lib/ExtUtils/t/00setup_dummy.t" ! ........ok
$ perl lib/ExtUtils/t/00setup_dummy.t ! ........ok
$ say "perl lib/ExtUtils/t/backwards.t" !............ok
$ perl lib/ExtUtils/t/backwards.t !............ok
$ say "perl lib/ExtUtils/t/basic.t" !................FAILED at test 22
$ perl lib/ExtUtils/t/basic.t !................FAILED at test 22
$ say "perl lib/ExtUtils/t/bytes.t" !................ok
$ perl lib/ExtUtils/t/bytes.t !................ok
$ say "perl lib/ExtUtils/t/Command.t" !..............ok
$ perl lib/ExtUtils/t/Command.t !..............ok
$ say "perl lib/ExtUtils/t/Constant.t" !.............FAILED at test 5
$ perl lib/ExtUtils/t/Constant.t !.............FAILED at test 5
$ exit
And if I run that from the source directory I obtain
the following result (with a PERL_ROOT already defined in
the SYSTEM table pointing to a perl 5.6.1 installation):
$ @test_mm
perl lib/ExtUtils/t/00compile.t
Can't locate Test/More.pm in @INC (@INC contains: t/lib
perl_root:[lib.VMS_AXP.5_6_1] perl_root:[lib]
perl_root:[lib.site_perl.VMS_A
XP] perl_root:[lib.site_perl] /perl_root/lib/site_perl .) at
lib/extutils/t/00compile.t line 15.
BEGIN failed--compilation aborted at lib/extutils/t/00compile.t line 15.
%RMS-F-SYN, file specification syntax error
Which looks like the type of troule that arises from
popping a CPAN ready kit into the perl core without
modification (does anyone besides me and maybe the pumpking
find those differences annoying?)
One other thing to note is that the PERL_SETUP.COM that
gets written out by CONFIGURE.COM will, if you ran
configure with the default of C<@configure "-des">
set up a definition for PERL_ROOT that does not
point to your source directory. For example,
if you build in:
DKA0:[UTILS.JP_PERL.PERL]
then PERL_SETUP.COM will default to making
PERL_ROOT be:
DKA0:[UTILS.JP_PERL.PERL_ROOT.]
a place that should not have any files
in it (including a descrip.mms file!)
until after you have run:
mmk install
after which there should be no descrip.mms file
there either.
By the way, it should be possible to build and test perl
with or without a PERL_ROOT defined. The build of the core
should not care about that rooted logical name at all.
If you find that is not the case then we have a problem
that needs fixing. I hope that information helps.
Peter Prymmer
