146 lines
6.6 KiB
Plaintext
146 lines
6.6 KiB
Plaintext
|
|
||
|
VMS (OpenVMS):
|
||
|
|
||
|
On VMS, two build methods are provided: a command procedure, and
|
||
|
description files for MMS or MMK. Both methods must be run from
|
||
|
the main directory, not the [.VMS] subdirectory.
|
||
|
|
||
|
A simple build using the command procedure looks like this:
|
||
|
@ [.VMS]BUILD_UNZIP.COM
|
||
|
|
||
|
A simple build using MMS or MMK looks like this:
|
||
|
MMS /DESCRIP = [.VMS]DESCRIP.MMS ! Or, with MMK, ...
|
||
|
MMK /DESCRIP = [.VMS]DESCRIP.MMS
|
||
|
|
||
|
Various options for each build method are explained in comments in
|
||
|
the main builder file, either BUILD_UNZIP.COM or DESCRIP.MMS.
|
||
|
|
||
|
Here are some more complex build examples:
|
||
|
|
||
|
o Build with the large-file option enabled (non-VAX only):
|
||
|
|
||
|
@ [.VMS]BUILD_UNZIP LARGE
|
||
|
or:
|
||
|
MMS /DESC = [.VMS] /MACRO = LARGE=1
|
||
|
|
||
|
o Re-link the executables (small-file and large-file):
|
||
|
|
||
|
@ [.VMS]BUILD_UNZIP LINK
|
||
|
@ [.VMS]BUILD_UNZIP LARGE LINK
|
||
|
or
|
||
|
MMK /DESC = [.VMS] CLEAN_EXE ! Deletes existing executables.
|
||
|
MMK /DESC = [.VMS] ! Builds new executables.
|
||
|
MMK /DESC = [.VMS] /MACRO = LARGE=1 CLEAN_EXE
|
||
|
MMK /DESC = [.VMS] /MACRO = LARGE=1
|
||
|
|
||
|
o Build a large-file product from scratch, for debug, getting
|
||
|
compiler listings and link maps:
|
||
|
|
||
|
MMS /DESC = [.VMS] CLEAN
|
||
|
MMS /DESC = [.VMS] /MACRO = (DBG=1, LARGE=1. LIST=1)
|
||
|
|
||
|
On VAX, the builders attempt to cope with the various available C
|
||
|
compilers, DEC/Compaq/HP C, VAX C, or GNU C. If DEC/Compaq/HP C is
|
||
|
not available or not desired, comments in the relevant builder file
|
||
|
explain the command-line options used to select a different
|
||
|
compiler.
|
||
|
|
||
|
By default, Zip uses (and UnZip supports) the "deflate" compression
|
||
|
method. To add support for the optional "bzip2" compression method,
|
||
|
first obtain and build the bzip2 software (http://www.bzip.org/ or,
|
||
|
for a more VMS-friendly kit, http://antinode.info/dec/sw/bzip2.html).
|
||
|
Then, define the macro IZ_BZIP2 on the BUILD_UNZIP.COM or MMS/MMK
|
||
|
command line to specify the directory where the bzip2 files may be
|
||
|
found. For example:
|
||
|
|
||
|
@ [.VMS]BUILD_UNZIP LARGE -
|
||
|
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_4B_VMS]
|
||
|
or:
|
||
|
MMS /DESC = [.VMS] /MACRO = (LARGE=1, -
|
||
|
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_4B_VMS])
|
||
|
|
||
|
Note that historically, UnZip has been built with the default
|
||
|
compiler option, /NAMES = UPPERCASE, while bzip2 is normally built
|
||
|
with /NAMES = AS_IS, to avoid name collisions. With modern
|
||
|
compilers, the "#pragma names" directives in [.VMS]BZLIB.H will
|
||
|
handle these differences without user intervention. An old
|
||
|
compiler (for example, DEC C V4.0-000) will emit complaints
|
||
|
%CC-I-UNKNOWNPRAGMA, and will mishandle the bzip2 library function
|
||
|
names, which will cause the link to fail. To solve this problem,
|
||
|
either build the bzip2 BZ_NO_STDIO object library with /NAMES =
|
||
|
UPPERCASE, or else build UnZip with /NAMES = AS_IS. For example:
|
||
|
|
||
|
@ [.VMS]BUILD_UNZIP LARGE "CCOPTS=/NAMES=AS_IS" -
|
||
|
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_4B_VMS]
|
||
|
or:
|
||
|
MMS /DESC = [.VMS] /MACRO = (LARGE=1, "CCOPTS=/NAMES=AS_IS", -
|
||
|
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_4B_VMS])
|
||
|
|
||
|
System-architecture-specific files (like objects and executables)
|
||
|
are placed in separate directories, such as [.ALPHA], [.IA64], or
|
||
|
[.VAX]. Large-file products get their own directories, [.ALPHAL]
|
||
|
or [.IA64L]. On VAX, VAX C products are placed in [.VAXV], GNU C
|
||
|
products in [.VAXG]. Each product builder announces what the
|
||
|
destination directory will be when it is run.
|
||
|
|
||
|
Common files, such as the help libraries (UNZIP.HLP for the default
|
||
|
UNIX-like command-line interface, UNZIP_CLI.HLP for the VMS-like
|
||
|
command-line interface), are placed in the main directory. With a
|
||
|
mixed-architecture VMS cluster, the same main directory on a shared
|
||
|
disk may may be used by all system types. (Using the NOHELP option
|
||
|
with BUILD_UNZIP.COM can keep it from making the same help files
|
||
|
repeatedly.) Building the help files is detailed below.
|
||
|
|
||
|
Completing installation:
|
||
|
|
||
|
To complete the installation, the executables may be left in place,
|
||
|
or moved (or copied) to a convenient place. While other methods
|
||
|
(like DCL$PATH) exist, most users define symbols to make the UnZip
|
||
|
executables available as foreign commands. These symbol definitions
|
||
|
may be placed in a user's SYS$LOGIN:LOGIN.COM, or in a more central
|
||
|
location, like SYS$MANAGER:SYLOGIN.COM. Typical symbol definitions
|
||
|
might look like these:
|
||
|
|
||
|
UNZIP :== $ dev:[dir]UNZIP.EXE ! UNIX-like command line.
|
||
|
or:
|
||
|
UNZIP :== $ dev:[dir]UNZIP_CLI.EXE ! VMS-like command line.
|
||
|
|
||
|
On a non-VAX system, different symbols could be defined for the
|
||
|
small-file and large-file programs. For example:
|
||
|
|
||
|
UNZIPS :== $ dev:[dir.ALPHA]UNZIP.EXE ! UNZIPS = small-file UnZip.
|
||
|
UNZIP*L :== $ dev:[dir.ALPHAL]UNZIP.EXE !UNZIP[L] = large-file UnZip.
|
||
|
|
||
|
The builders create help text files, UNZIP.HLP and UNZIP_CLI.HLP.
|
||
|
These may be incorporated into an existing help library, or a separate
|
||
|
UnZip help library may be created using commands like these, using
|
||
|
either UNZIP.HLP (as shown) or UNZIP_CLI.HLP:
|
||
|
|
||
|
LIBRARY /HELP dev:[dir]existing_library.HLB UNZIP.HLP
|
||
|
|
||
|
LIBRARY /CREATE /HELP UNZIP.HLB UNZIP.HLP
|
||
|
|
||
|
UnZip help may then be accessed from a separate UnZip help library
|
||
|
using a command like:
|
||
|
|
||
|
HELP /LIBRARY = device:[directory]UNZIP.HLB
|
||
|
|
||
|
For greater ease, the user (or system manager) may define a
|
||
|
HLP$LIBRARY logical name to allow the HELP utility to find the UnZip
|
||
|
help library automatically. See HELP HELP /USERLIBRARY for more
|
||
|
details. The command procedure HLP_LIB_NEXT.COM may be used to
|
||
|
determine the next available HLP$LIBRARY logical name, and could be
|
||
|
adapted to define a HLP$LIBRARY logical name for a UnZip help library.
|
||
|
|
||
|
The builders also create VMS message files, UNZIP_MSG.EXE, in the
|
||
|
destination directory with the program executables. A user may
|
||
|
gain DCL access to the UnZip error messages using a command like:
|
||
|
|
||
|
SET MESSAGE device:[directory]UNZIP_MSG.EXE
|
||
|
|
||
|
For system-wide access, the system manager may move or copy this
|
||
|
file to SYS$MESSAGE, although this could cause some confusion if
|
||
|
multiple versions of UnZip are used on the system, and their error
|
||
|
message source files differ.
|
||
|
|