Shareware Overload/ShartewareOverload.cdr/clipart/gs22.zip/MAKE.DOC

Text File | 1991-05-11 | 16KB | 379 lines

   Copyright (C) 1989, 1990, 1991 Aladdin Enterprises.  All rights reserved.
   Distributed by Free Software Foundation, Inc.

This file is part of Ghostscript.

Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY.  No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing.  Refer
to the Ghostscript General Public License for full details.

Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License.  A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities.  It should be in a file named COPYING.  Among other
things, the copyright notice and this notice must be preserved on all
copies.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This file, make.doc, describes how to install Ghostscript, and how to
build Ghostscript executables from source.

For an overview of Ghostscript and a list of the documentation files, see
README.

********
******** Installing Ghostscript
********

To install the interpreter, you need:
    - The interpreter executable:
        - On MS-DOS and VMS systems, gs.exe.
        - On Unix systems, gs.
    - The interpreter initialization files, gs_init.ps, gs_statd.ps,
      gs_fonts.ps, and symbol_e.ps.
    - The font map, Fontmap.
    - The default font, uglyr.gsf.

See use.doc for a description of the search algorithm used to find these
files.

You do not need any of these files when using the library; however, the
library currently provides no way to install fonts.  This is obviously
ridiculous and will be fixed sometime in the future.

********
******** Building Ghostscript from source
********

Ghostscript is generally distributed in the form of a compressed tar file.
When unpacked, this file puts all the Ghostscript files in a directory
called gs.  Ghostscript is also available in the form of a PC-compatible
ZIP file.

Ghostscript is described by a collection of several makefiles:

    ghost.mak - a generic makefile used on all platforms (except VMS).
    gdevs.mak - a makefile listing all the device drivers.
    *.mak - the makefiles for specific platforms.

You may need to edit the platform-specific makefile if you wish to change
any of the following options:

    - The default search path(s) for the initialization and font files
(macro GS_LIB_DEFAULT);

    - The debugging options (macro GENOPT);

    - The set of device drivers to be included (macros DEVICES,
DEVICE_DEVS, and DEVICE_OBJS);

    - The set of optional features to be included (macro FEATURES).
Currently no such features are defined; this is a place-holder.

The platform-specific makefile will include comments describing all of
these items except the DEVICE* options.  The DEVICE* options are described
in gdevs.mak, even though the file that must be edited is the
platform-specific makefile.

The makefiles distributed with Ghostscript define these options as
follows:

    - GS_LIB_DEFAULT: on Unix systems, the current directory at build
time; on MS-DOS systems, C:\GS.

    - GENOPT: no debugging code included in the build.

    - DEVICES/DEVICE_DEVS/DEVICE_OBJS: platform-specific, see below.

    - FEATURES: none.

There are also platform-specific options described below under the
individual platforms.  See the "Options" section near the beginning of the
relevant makefile for more information.

If you are including a dot-matrix printer driver, you may wish to
customize the density parameters in gdevs.mak.

To build the interpreter, you need all the .h and .c files (and .asm files
for MS-DOS) included in the distribution, as well as the makefiles.

The command
    make clean
removes all the files created by the build process (relocatables,
executables, and miscellaneous scratch files).  If you want to save the
executable, you should move it to another directory first.

********
******** How to build Ghostscript from source (MS-DOS version) ********
********

The makefile distributed with Ghostscript selects the following devices
for inclusion in the build:

    VGA and EGA display drivers;
    Epson dot matrix printer at 120 x 60 DPI;
    H-P DeskJet and LaserJet.

To build Ghostscript, you need one of the Borland C/C++ development
systems, either Turbo C (version 2.0 or later) or Turbo C++ or Borland C++
(version 1.0 or later); specifically, the compiler, 'make' utility, and
linker.  You also need either the Borland assembler (version 1.0 or later)
or the Microsoft assembler (version 4.0 or later).  Before compiling or
linking, you should execute

    echo !include "turboc.mak" >makefile
(for Turbo C), or
    echo !include "tbcplus.mak" >makefile
(for Turbo C++ or Borland C++).

Besides the source files and the makefiles, you need:
    turboc.cfg (the flags and switches for Turbo C)
    gt.tr (the linker commands for the library test program - optional)
    gs.tr (the linker commands for the interpreter)

There are extensive comments in the file msdos.mak 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.

As noted above, the default configuration also generates an executable
that assumes the directory where 'make' was run should be the final
default directory for looking up the Ghostscript initialization and font
files.

To build the Ghostscript executable, all you need to do is give the
command
    make

There is a special 'make' target that simply attempts to compile all the
.c files in the current directory.  Some of these compilations will fail,
but the ones that succeed will go considerably faster, because they don't
individually pay the overhead of loading the compiler into memory.  So a
good strategy for building the executable for the first time, or after a
change to a very widely used .h file, is:
    make begin
and then
    make
to do the compilations that failed the first time.

Note: if you get the Ghostscript sources from a Unix 'tar' file and unpack
the file on a MS-DOS machine, the files will all have linefeed instead of
carriage return + linefeed as the line terminator, which will make the C
compiler unhappy.  I don't know the simplest way to fix this: just reading
each file into an editor and writing it back out again may be sufficient.

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

The makefile distributed with Ghostscript selects the following devices
for inclusion in the build:
    X Windows driver only.

Before compiling or linking, you should execute

    cp unix-cc.mak makefile
or    cp unix-gcc.mak makefile

If the X11 client header files are located in some directory which your
compiler does not automatically search, you must change the X11 entry in
the makefile to include a specific -I switch.  See the comment just before
the entry for gdevx.$(OBJ) in your chosen makefile.

The only important customization of the X11 driver is the choice of
whether or not to use a backing pixmap.  If you use a backing pixmap,
Ghostscript windows will redisplay properly when they are covered and
exposed, but drawing operations will go slower.  This choice is controlled
by a line in the file gdevx.c that says
    private int use_backing = 1;
Changing this line to read
    private int use_backing = 0;
will disable the use of a backing pixmap.  However, portions of the
Ghostscript window may not be properly redrawn after the window is
restored from an icon or exposed after being occluded by another window.

Some versions of the X server do not implement tiling properly.  This will
show up as broad bands of color where dither patterns should appear.  If
this happens, change
    #define use_XSetTile 1
to
    #define use_XSetTile 0
and recompile.  The result will run a lot slower, but the output will be
correct.  (Report the problem to whoever made your X server.)

Currently Ghostscript is set up to compile and link in a generic Unix
environment.  Some Unix environments may require changing the LDPLAT 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 almost
all 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
converted code.  If you want to change this name for some reason, it is
defined in unix-cc.mak.

Platform-specific notes
-----------------------

There is apparently a bug in the MIPS C compiler which causes gxdither.c
to compile incorrectly if optimization is enabled (-O).  Until a
work-around is found, do not use -O with the MIPS C compiler.

On the Apollo, you must run the compiler in ANSI-compatible mode (i.e.,
set AK= <null string> in the makefile); otherwise, it gives incorrect
error messages for any function declared as returning a float value.

Due to a compiler bug, if you are building Ghostscript on an Intel 80386
system using a version of gcc older than version 1.38, you must not use
the -O option.

GNU make 3.59 can't handle the final linking step in some cases; use the
platform's standard make (e.g., /bin/make) if this happens.

********
******** How to build Ghostscript from source (VAX/VMS version) ********
********

The files VMS-CC.MAK and VMS-GCC.MAK are VMS DCL command files which
build Ghostscript from scratch using either the DEC C compiler, CC, or
the Free Software Foundation's GNU C compiler, GCC.  Accordingly, you
must have one of these two compilers installed in order to build
Ghostscript.  (Other C compilers may work: CC and GCC are the only two
compilers tested to date.)  These two command files build and store
the Ghostscript library in the object library GS.OLB.  If you have
DECwindows (X11) installed on your system, the executable images GS.EXE,
GT.EXE, and XLIB.EXE will also be built.

The only important customization of the X11 driver is the choice of
whether or not to use a backing pixmap.  If you use a backing pixmap,
Ghostscript windows will redisplay properly when they are covered and
exposed, but drawing operations will go slower.  This choice is controlled
by the line in the file gdevx.c that reads
    private int use_backing = 1;
Changing this line to read
    private int use_backing = 0;
will disable the use of a backing pixmap.  However, portions of the
Ghostscript window may not be properly redrawn after the window is
restored from an icon or exposed after being occluded by another window.

Some versions of the X server do not implement tiling properly.  This will
show up as broad bands of color where dither patterns should appear.  If
this happens, change
    #define use_XSetTile 1
to
    #define use_XSetTile 0
and recompile.  The result will run a lot slower, but the output will be
correct.  Report the problem to DEC, or whoever made your X server.

Ghostscript uses ANSI syntax for function definitions. Thus, when using
the DEC C compiler, each .C file is converted to the older C syntax defined
in the first edition of Kernighan and Ritchie and stored in a .CC file.
This step is performed by VMS-CC.MAK using the ansi2knr utility included
in the Ghostscript distribution.  If you are building a debuggable
configuration, the .CC files will be left behind by VMS-CC.MAK for use by
the VMS Debugger; otherwise, they will be deleted.

If you have DEC's C compiler, issue the DCL command
        $ @VMS-CC.MAK
to build Ghostscript.  If you have GNU C, issue the DCL command
        $ @VMS-GCC.MAK
to build Ghostscript.

The option "DEBUG" may be specified with either command file in order to
build a debuggable Ghostscript configuration:
        $ @VMS-CC.MAK DEBUG    -or-   $ @VMS-GCC.MAK DEBUG

In order to specify switches and file names when invoking the interpreter,
define GS as a foreign command:
        $ GS == "$disk:[directory]GS.EXE"
where "disk" and "directory" specify the disk and directory where Ghostscript
is located.  For instance,
        $ GS == "$DUA1:[GHOSTSCRIPT]GS.EXE"
To allow the interpreter to be run from any directory, define the logical
GS_LIB which points to the Ghostscript directory
        $ DEFINE GS_LIB disk:[directory]
This allows Ghostscript to locate its initialization files stored in the
Ghostscript directory -- see use.doc for further details.  Finally, to
invoke the interpreter, merely type GS.  Although DCL normally converts
unquoted parameters to upper case, C programs receive their parameters in
lower case.  That is, the command
        $ GS -Isys$login:
passes the switch "-isys$login" to the interpreter.  To preserve the
case of switches, enclose them in double quotes; e.g.,
        $ GS "-Isys$login:"

********
******** A guide to the files ********
********

General
-------

There are very few machine dependencies in Ghostscript.  A few of the .c
files are machine-specific.  These have names of the form
    gp_<platform>.c
specifically
    gp_dos.c
    gp_unix.c
    gp_vms.c
There are also some machine-specific conditionals in files with names
<something>_.h, and in gdevmem.c.  If you are going to extend Ghostscript
to new machines or operating systems, you should check all the source
files (both .c and .h) for ifdef's on things other than DEBUG, and you
should probably count on making a new makefile and a new gp_ file.

Library
-------

gt.c is a test driver for the library.

Files beginning with gs, gx, or gz (both .c and .h), other than gs.c, are
the Ghostscript library.  Files beginning with gdev are device drivers or
related code, also part of the library.  Other files beginning with g are
library files that don't fall neatly into either the kernel or the driver
category.

Interpreter
-----------

gs.c is the main program for the language interpreter.

Files beginning with z are Ghostscript operator files.  The names of the
files generally follow the section headings of the operator summary in
section 6.2 of the PostScript manual.  Files beginning with z2 implement
Level 2 operators, which are not automatically included in the
interpreter.

.c files beginning with i, and .h files not beginning with g, are the
rest of the interpreter.  Those beginning with i2 provide Level 2
functions.  See the makefile for a little more information on how the
files are divided functionally.

There are a few files that are logically part of the interpreter, but that
are potentially useful outside Ghostscript, whose names don't begin with
either g, z, or i:

    stream.c (a stream package that is only necessary because neither
Unix C nor Turbo C provides source code for their file system library);

    trace.c (a procedure tracing package for debugging) and utrace.c
(the Unix stub for trace.c).