make.txt

实现并行算法

There are extensive comments in the aforementioned .mak files
regarding various configuration parameters.  If your configuration is
different from the following, you should definitely read those
comments and see if you want or need to change any of the parameters:
	- The compiler files are in c:\tc (for Turbo C) or c:\bc (for
Turbo C++ or Borland C++) and its subdirectories.
	- You are using the Borland assembler (tasm).
	- You want an executable that will run on any PC-compatible,
regardless of processor type (8088, 8086, V20, 80186, 80286, V30, 80386,
80486) and regardless of whether a math coprocessor (80x87) is present.

NOTE: Borland C++ 3.0 has two problems that affect Ghostscript (these
problems are fixed in Borland C++ 3.1):

	- The assembler, tasm, often crashes when attempting to
assemble gdevegaa.asm.  If this happens, try again, or use another
assembler (e.g., an older version of tasm) if you have one, or set
USE_ASM=0 in the makefile.

	- The math library for Microsoft Windows, mathwl.lib, has a
bug that causes floating point numbers to print incorrectly.  Contact
Borland for a corrected version.

NOTE: Borland C++ 4.52 has a bug that causes the 32-bit Windows executable
to fail during startup.  Borland has provided a patch for this bug on the
file bc45xp1.zip, accessible as a link from
http://loki.borland.com/cpp/Patchs.htm.

NOTE: Borland C++ 5.0 and 5.01 have a code generator bug that generates
incorrect code for the construct !file_is_valid().  Do not attempt to
compile Ghostscript with these compilers.  If you want to report this bug to
Borland, send them the result of compiling ziodev.c and tell them to look at
the code generated for file_is_valid() and !file_is_valid().

If you are compiling Ghostscript with Turbo C++ 1.0, remove the
`.swap' directive from bc.mak, and use the -s switch on the `make'
command line.  (All later versions of the Borland environment
recognize this directive.)

Note that although the Microsoft Windows version of Ghostscript will
run under Windows 3.0, it uses routines from the Windows 3.1 SDK, so
you need the Windows 3.1 SDK and header files to compile it.  In
practice, this means that you need Borland C++ 3.1; Borland C++ 3.0
doesn't include the necessary headers.

If building for the MS Windows Win32s environment, you need bcc32.cfg
instead of turboc.cfg.  The make process will stop after it has created
genarch.exe.  You should then run 'win genarch arch.h', wait until genarch
has finished and then exit MS Windows.  Then type 'make' again to restart
the make process.

If building for MS Windows NT, you also need bcc32.cfg instead of
turboc.cfg, but the make process will run to completion automatically.

Microsoft environment
---------------------

To compile Ghostscript with the Microsoft environment, you need Microsoft
Visual C++ 1.0 or later with its associated `nmake' utility and linker.
Before compiling or linking, you should execute
	echo !include msc.mak >makefile

Besides the source files and the makefiles, you need:
	gs.tr (the linker commands for the interpreter)
	*.bat (a variety of batch files used in the build process)

All previous versions of Microsoft C/C++ are of such poor quality that we
strongly advise you not to attempt to compile Ghostscript with them.  In
particular, C/C++ 7.0 is the first version that is even close to being
ANSI-compliant, and its 'nmake' program is very unreliable (it crashes
partway through the build process with a variety of error messages, or no
error message) and cannot write its error messages to a file.

Aladdin Enterprises does not currently have a copy of the Microsoft
compiler.  If you encounter problems with it, we will not be able to help
you; please post them to the Usenet gnu.ghostscript.bug newsgroup.

Watcom environment
------------------

Before compiling, change the definition of the WCVERSION macro in the
makefile (watc.mak or watcwin.mak) to the version of the Watcom compiler you
are using.  This is necessary to handle some minor incompatibilities between
versions.

To avoid annoying messages from the DOS extender, add the line
	set DOS4G=quiet
to your autoexec.bat file. 

To compile Ghostscript with the Watcom compiler, create a makefile by
executing

	echo !include watc.mak >makefile

or

	echo !include watcwin.mak >makefile

To build Ghostscript, execute

	wmakebat

This constructs a build script and then executes it.  (This roundabout
procedure is necessary because Watcom chose to implement wmake in a way that
requires reading both the entire makefile and the entire current directory
into the limited 640K MS-DOS address space.)

Note that Watcom C/386 version 8.5 does not include wmakel (the 32-bit
version of wmake).  If this is the version that you have, use wmake instead,
i.e., edit wmakebat.bat to change wmakel to wmake.

If you get an "Error(F01): Out of memory" with Watcom 8.5, you may wish to
try reducing the total size of the makefiles by editing devs.mak to remove
drivers that you don't ever intend to use.  If you still get this error,
contact Watcom technical support; they will be able to send you the wmakel
program, probably at no charge.

DesqView/X and djgcc/djgpp environment
--------------------------------------

The name of the makefile for this environment is dvx-gcc.mak.

The DesqView/X port of Ghostscript was contributed by Tom Brosnan
([e-mail]), with further contributions by Stephen Turnbull
([e-mail]).  It uses djgcc (DJ Delorie's MSDOS port
of gcc) for compiling.  djgcc assumes that go32.exe is in your search path.
You need to set an environment variable to tell go32 where to put any
paging files, e.g.

    set GO32TMP=e:/tmp

If you don't have go32.exe, you can get it from Internet host
oak.oakland.edu.  The extender and minimum run-time environment are in the
file djeoeXXX.zip, where XXX is the version number (currently 112).
Patched versions of the extender (as well as other components) are found in
the files djXXXmY.zip, XXX is again the compiler version, Y is the
patchlevel.  Y is currently 2.  People who are just running the executable
need only get the file with the highest level of Y that contains GO32.EXE
and do "unzip -j djXXXmY go32.exe" (InfoZIP) or "pkunzip djXXXmY go32.exe"
(PKWare), then move the extender to their PATH.  If you do not have a
hardware FPU, you will also need the floating point emulator EMU387 found
in djeoeXXX.zip (and possibly in the patch releases as well).  You MUST use
an emulator designed to work with GO32; the emulators often found as TSRs
will not work.  See the file README found in djeoeXXX.zip, or the file
README.1ST in pub/msdos/djgpp on Simtel for further information.

The DJGPP v1.12 compiler suite is known to have problems with linking
large file sets.  If you run into this problem, you can work around it
by using the v1.11 GO32 as follows:
(1) get dj111m5.zip from turnbull.sk.tsukuba.ac.jp:/pub/djgpp/1.11
(2) unzip GO32.EXE.  Be careful not to overwrite other versions!
(3) rename it, eg, to GO111M5.EXE
(4) move the renamed GO32.EXE to your path
(5) stubedit ld.exe:  (the stubedit utility is part of djeoe112.zip)
    (a) change the extender name to the one you chose in (3).  The
        .EXE extension may be omitted
    (b) change the version required to 1.11
    (c) accept the defaults for the remaining options.

Stephen Turnbull observed the following two problems with DJGPP v2.0-beta2.

(1) The v1.12 stdio.h defined a number of flags for manipulating the
    various characteristics of the streams being processed, such as
    _IORD, _IOWRT, etc.  These are missing from v2.0-beta2.  I don't
    know enough about the new libc.a to guess whether this is an
    oversight or these functions have a new (Posix?) interface.
    [Caveat: In Ghostscript the compiler error can be silenced by
    adding "#define _IOWRT 00002" to the file gp_dvx.c.  I don't know
    that this is correct in the new libraries.  I suspect there is no
    real loss in Ghostscript to removing the offending flag
    manipulation from gp_open_printer() in gp_dvx.c, as it is a
    performance optimization.]

(2) The big problem is linking with third-party libraries not compiled
    with v2.0.  In particular, QuarterDeck's contributed Xlib
    (compiled with DJGPP v1.12 (original release).  Unfortunately,
    v1.12 uses the usual macros for character classification and
    implementation of the stdio streams.  This leads to long lists of
    complaints from the linker about undefined references to '_ctype_'
    (the table of character type flags) and '_iob' (the table indexed
    by file descriptors) when processing Xlib functions.

********
******** How to build Ghostscript from source (Mac version) ********
********

There are additional Mac-specific source files in a separate distribution
from the rest of Ghostscript.  In addition to the standard Ghostscript
sources, you will need the following files:

    macgs-v1.0-src.sit    - the source files, StuffIt archive.
    manual.txt            - the manual as unformatted text
    readme.txt            - this file

These should be in the mac directory located in the same place you retrieved
the rest of the Ghostscript distribution.

The first file is a StuffIt archive.  If you do not have a program to expand
it, you should get the free StuffIt Expander program from your favorite
Macintosh archive.

In the standard method of building Ghostscript, all of these files (except
the jpeg) get unpacked into one big directory.  The jpeg stuff gets unpacked
into a directory called jpeg-6 in the main directory.  The Macintosh stuff
also gets unpacked into its own directory, called 'Mac Specific'.  However,
if you like (and I do) you can divide up all these files into the following
hierarchy:

    Ghost Dev
        files -- all *.ps, *.txt, and other non-build files
        fonts -- all the fonts
        src -- *.c, *.h, *.mak
        jpeg-6 -- the jpeg files
        Mac Specific -- the mac files
        MPW Build -- empty directory used for building under MPW

Once you get everything laid out, take a look at the file Worksheet in the
mac specific folder for complete steps to build the system with either MPW
or CodeWarrior.

********
******** How to build Ghostscript from source (Unix version) ********
********

The makefile distributed with Ghostscript selects the following devices
for inclusion in the build:
	Display: X Windows driver.
	File output: pbm, pbmraw, pgm, pgmraw, ppm, and ppmraw drivers.

Before compiling or linking, you should execute

	ln -s unix-cc.mak makefile
or	ln -s unix-gcc.mak makefile
or	ln -s unixansi.mak makefile

(if your Unix system doesn't support symbolic links, omit the -s switch)
depending on whether your C compiler is a traditional Kernighan & Ritchie C
compiler, gcc, or an ANSI C compiler other than gcc respectively.  (If you
want to use gcc in traditional mode, use unix-cc.mak and define the CC macro
to refer to gcc.)

The unix-*.mak files are actually generated mechanically from *head.mak,
*tail.mak, unix-end.mak, gs.mak, jpeg.mak, libpng.mak, zlib.mak, and
devs.mak by a script called tar_cat.  If for some reason your copy of
Ghostscript doesn't include the unix-*.mak files, run tar_cat to construct
them.  If you wish to edit any part of the makefile,

	DO NOT EDIT THE FILE NAMED makefile OR unix{ansi,cc,gcc}.mak.
	EDIT THE ORIGINAL COMPONENT MAKEFILE (*head.mak, *tail.mak,
	unix-end.mak, gs.mak, jpeg.mak, libpng.mak, zlib.mak, OR devs.mak)
	AND RUN tar_cat AGAIN.

Consult tar_cat to find the names of the component files.

The *head.mak files explicitly compile and link the libpng and zlib
libraries into the executable.  If your Unix system already includes these
libraries (probably in /usr/lib/libpng.{a,so} and libz.{a,so}) and you would
rather use the system copies, change the definition of SHARE_LIBPNG and/or
SHARE_ZLIB from 0 to 1 in the relevant *head.mak file, run tar_cat, and
recompile.  Note that if you do this, you will get non-DEBUG versions of
these libraries, even if you selected DEBUG in the Ghostscript makefile.

If the X11 client header files are located in some directory which your
compiler does not automatically search, you must change the XINCLUDE macro
the makefile to include a specific -I switch.  See the comment preceding
XINCLUDE in the makefile.

Currently Ghostscript is set up to compile and link in a generic Unix
environment.  Some Unix environments may require changing the LDFLAGS
macro in the makefile.

All you need to do to make an executable is invoke the shell command
	make

Ghostscript uses ANSI syntax for function definitions. Because of this,
when compiling with cc, it must preprocess each .c file to convert it to
the older syntax defined in Kernighan and Ritchie, which is what most
current Unix compilers (other than gcc) support.  This step is
automatically performed by a utility called ansi2knr, which is included in
the Ghostscript distribution.  The makefile automatically builds ansi2knr.

The ansi2knr preprocessing step is included in the makefile rule for
compiling .c files.  ansi2knr creates a file called _temp_.c to hold the