On Mon, 12 Feb 2001 [EMAIL PROTECTED] wrote:
>
> I've put together a pre-build G5.6-1 (trials-n-tribs2 :-) PCSI kit for the OpenVMS
> Freeware V5.0 CD-ROM and am seeking reasonable chunk(s) of perl code for use as an
> installation verification procedure (IVP). Suggestions or pointers?
>
> (nb: if final 5.6.1 (trial-infinite :-) shows up in time to permit me to kit and
> test the PCSI installation before I have to ship the Freeware V5.0 CD-ROM to
> manufacturing, I'll use that version. Else, it goes to the website and it waits
> for Freeware V5.1...)
As I think that other have pointed out the 'test' or 'check' target in the
generated descrip.mms file will invoke the running of the VMS version of
the perl regression test suite (up to 18,000 individual tests on VMS for
5.6.1 trial2; more that 20,000 tests on several unix platforms including
Tru64).
Note that the VMS perl build (as opposed to the Unix perl build) is set up
to build and test in one location then to "install" in either the same
location (which is the default) or in another location - but only by
properly specifying a "prefix" variable during the configure process.
Note that by doing a build like so:
$ set default dka200:[perl-5_6_1-trial2]
$ @configure "-des"
then the `mms install` step will run the perl script named installperl and
your PERL_ROOT logical name will point to dka200:[perl-5_6_1-trial2.].
However, if you build and install like so:
$ set def dka200:[perl-5_6_1-trial2]
$ @configure "-Dprefix=dka100:[perl-5_6_1.]" "-des"
then running `mms install` will place the perl installation tree into
dka100:[perl-5_6_1...] and write out a perl_setup.com procedure that
defines the PERL_ROOT logical name to be dka100:[perl-5_6_1.].
The advantage of going through the extra hassle of specifying the
"-Dprefix=dka100:[perl-5_6_1.]" parameter to configure.com is that all of
the intermediate file detritus: *.OBJ;, some *.OLB;, *.OPT; etc. files
will not be installed into dka100:[perl-5_6_1...] and the tree will be
smaller. The disadvantage is that one cannot then run the `mms test` IVP
except for in the dka200:[perl-5_6_1-trial2] directory owing to relative
file specs within many (but not all) of the tests (particularly those in
[.T.LIB]*.T and [.T.PRAGMA]*.T).
However you prepare an installed and re-installable PERL_ROOT tree a good
secondary way to verify that things are ship shape is to attempt to build,
test, and install an external modular extension such as any of the kits
from:
http://www.cpan.org/modules/by-category/04_Operating_System_Interfaces/VMS/
Re-writing the tests from the perl build tree in [.t.*]*.t to be
installable would entail a great deal of tedious work that noone has
bothered with. An example of the sort of thing that can be troublesome
includes the top of [.t.lib]abbrev.t like so:
#!./perl
print "1..7\n";
BEGIN {
chdir 't' if -d 't';
@INC = '../lib';
}
use Text::Abbrev;
print "ok 1\n";
which is expected to be run from a copy of perl.exe in the [.t]
subdirectory and the @INC = '../lib'; sets the perl library search path to
the lib subdirectory (dka200:[perl-5_6_1-trial2.lib] in the above example
build tree). That test would probably run against an installed perl just
fine if you comment out the BEGIN {} block, but there are a lot of such
tweaks all over more than 100 files that would need to be made to turn the
build tree test suite into an installed perl IVP. In fact many such tests
were explicitly written in that fashion so that the tests would test the
perl from the build directory and not some other perl that might have been
installed on the system (a problem that is strictly more severe on Unix
where perl binaries and @INC search paths are not expressed in terms of an
environment variable like $PERL_ROOT).
One thing you might try is to run `mms test` in your build tree, then run
`mms install` having specified a prefix that is not the same as the build
tree then backup the [.t...] directory into a saveset that you then unpack
elsewhere then set up your PERL_ROOT logical to point to the fresh
installation and try to run the whole test suite with TEST.COM on the
relocated tree. Certain tests (such as [.t.lib]abbrev.t) will fail and
could then be simply excluded from a relocatable saveset of perl's [.t]
directory (since you alrady have proved to yourself that they passed when
run from the build tree).
Peter Prymmer
