view release on metacpan or  search on metacpan

unzip-6.0/INSTALL  view on Meta::CPAN

       Human68k system (originated from Japan) and for Win32 (here only DBCS
       "double-byte character set" support).  The MBCS support should also be
       enabled on systems which are capable of using UTF-8 as native charset.
       For MBCS support, the C runtime library must supply implementations
       for the mblen() function and the MB_CUR_MAX runtime macro/function.
       The NO_MBCS symbol allows to explicitely disable MBCS support for
       testing purpose, or when MBCS support does not work as expected.

      HAVE_WORKING_ISPRINT
      NO_WORKING_ISPRINT
        The symbol HAVE_WORKING_ISPRINT enables enhanced non-printable chars
        filtering for filenames in the fnfilter() function.  On some systems
        (Unix, VMS, some Win32 compilers), this setting is enabled by default.
        In cases where isprint() flags printable extended characters as
        unprintable, defining NO_WORKING_ISPRINT allows to disable the enhanced
        filtering capability in fnfilter().  (The ASCII control codes 0x01 to
        0x1f are always escaped on ASCII systems.)

      DEBUG
        Used for debugging purposes; enables Trace() statements.  Generally
        it's best to compile only one or two modules this way.

      DEBUG_TIME
        Used for debugging the timezone code in fileio.c; enables TTrace()
        statements.  This code is only used for the freshen/update options
        (-f and -u), and non-Unix compilers often get it wrong.


(4) If you regularly compile new versions of UnZip and always want the same
    non-standard option(s), you may wish to add it (them) to the LOCAL_UNZIP
    environment variable (assuming it's supported in your makefile).  Under
    MS-DOS, for example, add this to AUTOEXEC.BAT:

        set LOCAL_UNZIP=-DDOSWILD -DDATE_FORMAT=DF_DMY

    You can also use the variable to hold special compiler options (e.g.,
    -FPi87 for Microsoft C, if the x87 libraries are the only ones on your
    disk and they follow Microsoft's default naming conventions; MSC also
    supports the CL environment variable, however).


(5) Run the make utility on your chosen makefile:

      Unix
        For most systems it's possible to invoke the makefile in place, at
        the possible cost of an ignorable warning; do "make -f unix/Makefile
        list" to get a list of possible system targets, and then "make -f
        unix/Makefile target" for your chosen target.  The "generic" target
        works for most systems, but if it fails with a message about ftime()
        unresolved or timezone redefined, do "make clean", "make help", and
        then either "make generic2" or "make generic3" as instructed.  If all
        else fails, read the makefile itself; it contains numerous comments.
        (One of these days we'll make a configure script that automates this
        procedure better.)

      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.

        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.)

        Some further information may be found in the files
        [.VMS]README. and [.VMS]00BINARY.VMS, though much of what's
        there is now obsolete.

      MS-DOS
        See the msdos\Contents file for notes regarding which makefile(s) to
        use with which compiler.  In summary:  pick one of msdos\makefile.*
        as appropriate, or (as noted above) use the OS/2 gccdos target for
        emx+gcc.  There is also an mscdos cross-compilation target in