Read the instructions in README.vms :-).
..... where it will tell you
$ @[.vms]test .exe "" -"v" [-.lib.extutils.t]basic.t
though the second argument should be "ndbg" instead of empty if you've got a VMS debug build.
The test failed with a file not found error, so I tried to run the 'mcr []miniperl "-V"' command.
It turns out that somehow while the when Perl was running the tests under MMS, it knew the value of Perl_root correctly, it did not have a correct definition in Perl_setup.com.
It had EAGLE$DQA0:[PROJECT_ROOT.PERL.PERL-5_8_4-RC1_ROOT.] when the files were really in EAGLE$DQA0:[PROJECT_ROOT.PERL.PERL-5_8_4-RC1.].
This looks like the proper print out for "-V", however the test driver is still not finding the file.
Ok, now I understand the meaning that the test path names must be relative to the [.t]directory.
Something is still wrong as now the test fails at 1 for doing a chdir(), where when run from the MMS script, it does not fail until test 28.
Ok, found it. The LIB tests are not standalone.
You must run 00setup_dummy before running basic, and after running basic, apparently run zz_cleanup_dummy to clean up the directories.
Now running the basic.t test interactively worked, so I do not know why it did not from an MMS interactive process.
ok 27 - install ok 28 ok 29 ok 30 - install dir created
So I still do not know what those two steps are or if my patch had anything to do with the test failure when it was run from MMS.
Looking now at the cwd.pm, I see that the better fix could be to change vms.c to return $ENV{'DEFAULT'} in UNIX syntax when desired. This appears to be a simple change to VMS.C.
In reviewing the spec.pm module, it appears that it selects the method that will be used for doing operations on the file. Apparently with the 'VMS' line commented out, it defaults to 'UNIX'.
It is not as I originally thought something that reports an operating environment of UNIX.
So while spec.pm could get a simple hack to fix, the proper fix would be to have [lib.file.spec]vms.pm to behave as it had received UNIX filenames if one of the DECC$FILENAME_UNIX_ONLY or DECC$FILENAME_UNIX_REPORT logical names is set. This may be the same module that needs to be changed to deal with "^" escaped filenames, and with filenames that are in "File ID Format".
Such a change to [lib.file.spec]vms.pm is probably beyond my ability at this point
Even a hack to spec.pm to be conditional in it's behavior appears to be beyond my present non-existent perl programming abilities.
So if tonight's build works, I will be using a locally customized spec.pm and moving on to attempt to build the next components of Mozilla.
Before I could send this, I discovered that the build worked, and this time all tests passed. However, I forgot to fix the problem Craig identified where I had a test inside of a loop that should be outside of it on the case preservation, so I am running the build and tests again. I should have some diffs tomorrow evening.
-John [EMAIL PROTECTED] Personal Opinion Only
