As I stated presviously in this thread, our PERL installation (Alpha VMS 8.3)
was apparently successful
and I had my previous questions answered, thank you.
I have an additional question, which is mostly academic so it's fine if I don't
get an answer.
Also I have some observations/suggestions related to the test procedures.
My question: if I were to do a new install on another VMS system, could I skip
the MMK TEST step?
Does this step do anything that is a prerequisite for the final MMK INSTALL
step? Does this step ever
fail in such a way as to make the INSTALL step impossible?
Some observations about the test procedures.
At the end of the MMK TEST job the following message appears:
### Since not all tests were successful, you may want to run some of
### them individually and examine any diagnostic messages they produce.
### See the INSTALL document's section on "make test".
### You have a good chance to get more information by running
### ./perl harness
### in the 't' directory since most (>=80%) of the tests succeeded.
I have performed both of these operations. The recommendation to run the
HARNESS test is not
mentioned in the README.VMS file. I'd suggest some mention in README.VMS about
HARNESS and the
motivation for running it as well (in addition to MMK TEST). My IMPRESSION is
that the information
these tests provide is not likely to be actionable by the unknowledgable bloke
who is just trying to
install PERL to satisfy a user request.
My experience running HARNESS:
It reported 64 failed tests (where MMK TEST reported 58). Most were the
same, but 8
failures were unique to HARNESS, 2 were unique to MMK TEST.
Tests which fail with MMK_TEST but not HARNESS:
io/socketpair.t (explicitly skipped by the HARNESS job)
op/lexsub.t (not mentioned by the HARNESS job)
Tests which fail with HARNESS but not MMK_TEST:
../lib/File/Copy.t
../lib/diagnostics.t
io/data.t
op/gv.t
op/lex.t
op/sigdispatch.t
run/switchC.t
run/switchx.t
(None of the above HARNESS failures were mentioned as being tested
in the MMK_TEST job.)
I ran the 8 tests uniquely reported as failed by HARNESS thru the procedure
$ @[.vms]test .EXE "" -"v" <testname>
That procedure found NO failures in any of those failed HARNESS tests.
It appears that failure is in the eye of the beholder.
Thanks,
Ed Miller SLAC NAL
________________________________
From: Craig Berry <craigbe...@mac.com>
Sent: Tuesday, February 16, 2021 6:38 AM
To: Miller, Edward S. <e...@slac.stanford.edu>; vmsperl@perl.org
<vmsperl@perl.org>
Subject: Re: Experience installing on Alpha VMS 8.3
> On Feb 15, 2021, at 10:47 PM, Miller, Edward S. via vmsperl
> <vmsperl@perl.org> wrote:
>
> During the run of all tests these two examples appear as
> lib/warnings ................................................... FAILED at
> test 710
> t/io/socketpair ................................................
> FAILED--unexpected output at test 0
Those paths are relative to the top-level directory.
> In the list of all failed tests at the end of the run of all tests they
> appear as
> ../lib/warnings.t
> io/socketpair.t
Those paths are relative to the t/ directory, and that's what you'll need for
running tests individually.
> The command
> $ @[.vms]test .EXE "" -"v" [.io]socketpair.t
> reruns that test with more detailed output. Using similar syntax for all
> failing tests that are reported
> with names specified as "t/..." also reruns the corresponding failing test.
>
> I didn't find the proper command to rerun the test on the warnings.t file (or
> any of the other test names that did
> not match the "t/..." syntax).
This oughta do it:
$ @[.vms]test .exe -"v" "../lib/warnings.t"
Apparently using VMS syntax filenames no longer works when running tests
outside of the t/ hierarchy, so if you gave it this:
$ @[.vms]test .exe -"v" [-.lib]warnings.t
it would try to run the mongrel filename t/[-.lib]warnings.t. Not sure when it
started doing that, but if you give it exactly what's in the list of failed
tests it should still work.
________________________________________
Craig A. Berry
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
