123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158 |
- VMS (OpenVMS):
- Building:
- 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_ZIP.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_ZIP.COM or DESCRIP.MMS.
- Note that on non-VAX systems with VMS V7.2 or later (and with a
- sufficiently new C compiler), Zip 3.0 can support files (both data
- files and Zip archives) larger than 2GB. For the greatest
- compatibility with previous Zip versions, the builders by default
- create old-style small-file programs. The user must specify the
- appropriate builder command-line option to create
- large-file-capable programs.
- Here are some more complex build examples:
- o Build with the large-file option enabled (non-VAX only):
- @ [.VMS]BUILD_ZIP LARGE
- or:
- MMS /DESC = [.VMS] /MACRO = LARGE=1
- o Re-link the executables (small-file and large-file):
- @ [.VMS]BUILD_ZIP LINK
- @ [.VMS]BUILD_ZIP 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 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_ZIP.COM or MMS/MMK command
- line to specify the directory where the bzip2 files may be found.
- For example:
- @ [.VMS]BUILD_ZIP LARGE -
- IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_3C_VMS]
- or:
- MMS /DESC = [.VMS] /MACRO = (LARGE=1, -
- IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_3C_VMS])
- Note that historically, Zip 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 Zip with /NAMES = AS_IS. For example:
- @ [.VMS]BUILD_ZIP LARGE "CCOPTS=/NAMES=AS_IS" -
- IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_3C_VMS]
- or:
- MMS /DESC = [.VMS] /MACRO = (LARGE=1, "CCOPTS=/NAMES=AS_IS", -
- IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_3C_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 (ZIP.HLP for the default
- UNIX-like command-line interface, ZIP_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 be used by all system types. (Using the NOHELP option
- with BUILD_ZIP.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 Zip
- 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:
- ZIP :== $ dev:[dir]ZIP.EXE ! UNIX-like command line.
- or:
- ZIP :== $ dev:[dir]ZIP_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:
- ZIPS :== $ dev:[dir.ALPHA]ZIP.EXE ! ZIPS = small-file Zip.
- ZIP*L :== $ dev:[dir.ALPHAL]ZIP.EXE ! ZIP[L] = large-file Zip.
- The builders create help text files, ZIP.HLP and ZIP_CLI.HLP.
- These may be incorporated into an existing help library, or a separate
- Zip help library may be created using commands like these, using
- either ZIP.HLP (as shown) or ZIP_CLI.HLP:
- $ LIBRARY /HELP dev:[dir]existing_library.HLB ZIP.HLP
- $ LIBRARY /CREATE /HELP ZIP.HLB ZIP.HLP
- Zip help may then be accessed from a separate Zip help library
- using a command like:
- $ HELP /LIBRARY = device:[directory]ZIP.HLB
- For greater ease, the user (or system manager) may define a
- HLP$LIBRARY logical name to allow the HELP utility to find the Zip
- 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 Zip help library.
- The builders also create VMS message files, ZIP_MSG.EXE, in the
- destination directory with the program executables. A user may
- gain DCL access to the Zip error messages using a command like:
- $ SET MESSAGE device:[directory]ZIP_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 Zip are used on the system, and their error
- message source files differ.
- Some further information may be found in the files
- [.VMS]00README.TXT and [.VMS]00BINARY.VMS, though much of what's
- there is now obsolete.
|