On Mon, 12 Feb 2001, Craig A. Berry wrote:
> At 12:18 PM -0800 2/12/01, Peter Prymmer wrote:
> >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.].
>
> Good reminder. Is there a pod somewhere that documents all of the
> options that can be fed in as command-line parameters? When creating
> pre-built kits it would be particularly helpful to configure the Perl
> administrator as 'system' instead of having the builder's e-mail
> address appear for every installation that uses the pre-built kit.
There are three documents: README.vms, @configure "-h", and to a lesser
extent the INSTALL. file (more appropriate for unix on the whole); all of
which could use some updating and general tweaking given the fact that
very few of the symbols we use do f$type() type checks before setting them
(prefix, usedevel and a few others being notable exceptions). But rather
than worry over updating the docs I'd like to update configure.com to
better correspond to INSTALL.
> >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.
>
> Yup, about half the size on Alpha.
>
> >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).
>
> Ah, but if we dump the contents of [.t...] from the build tree into
> the installed tree (perl_root:[t...]) as part of the install, won't
> all the relative dir specs work out, including [-.lib]? Then the
> tests could be run from there, and the installation could finish up
> by deleting perl_root:[t...]*.*;*. There might be tweaks to
> [.vms]test.com, including figuring out where in the install tree to
> put it, but I don't think it should be a major rewrite of the whole
> test concept.
>
> Remember, the problem is not that Hoff needs help testing Perl on his
> own machine, but that someone using the PCSI kit he's built (and
> knowing nothing about Perl, MM(S|K), etc.) could get a reasonable
> indication that s/he has a working Perl installation.
Oh sure I realize that. Actually I was also thinking that a quick way
around the trouble would be to come up with an IVP, perhaps a new file
called [.vms]re-test.com that could run many of the [.t...]*.* tests
against an installed perl and away from a [-.lib] installation. It would
basically do as much as test.com, except that it would have a longer list
of tests to exclude. The [.t...] that got shipped around for use with
re-test.com could include the full [.t...] tree from the perl source, but
it would not need to be installed and the skip lists:
@compexcl=('cpp.t');
@ioexcl=('argv.t','dup.t','fs.t','pipe.t');
@libexcl=('db-btree.t','db-hash.t','db-recno.t',
'gdbm.t','io_dup.t', 'io_pipe.t', 'io_poll.t', 'io_sel.t',
'io_sock.t', 'io_unix.t',
'ndbm.t','odbm.t','open2.t','open3.t', 'ph.t', 'posix.t');
could just be expanded a bit more than what is currently in test.com.
BTW Most other IVP's for VMS don't require extra files and disk space -
apart from the simple procedure optionally left behind in SYS$TEST (e.g.
SYS$TEST:DECC$IVP.COM or SYS$TEST:CXX$IVP.COM).
Peter Prymmer
