

The basic requirements are:
  ANSI C compiler;
  Xlib R4/5/6, maybe even R3 and m(ath) libraries.

If you have no access to an ANSI C compiler then read this:
  An ANSI C compiler is not strictly necessary with a suitable utility such
  as ansi2knr or unproto and a little editing the programs should compile on
  most systems. The ANSI C facilities used include constant string
  concatenations as well as the prototypes. I wrote in this flavour of C
  because it's what I started out learning and the compiler checks are very
  useful.

Machines tested:
  486DX2/66 PC under Linux 1.0.9 w/ XFree-3.1 and gcc 2.5.8
  HP9000/735 & HP9000/720 under HPUX-9.01
  DEC Alpha/Vax under VMS 6.1
  DEC Alpha under OSF/1 2.1
  Sun sun4m machine running under SunOS 4.1.3 with acc
    (previous xpgs version only)

Procedure for compiling:
  There are four compiler definitions you can choose - XPGSUSEPM, XSSUSEPM,
  EUROPPR and SILLYRAND options.

  The first option depends on how you want xpgs to animate the SIRDSs, your
  choice dictates whether the X server's pixmaps are used or not. If you
  have a crappy X server, (for instance a lowly X terminal) then you will
  not want to use pixmaps. Internally, the choice is between server-side
  pixmaps and client-side images. The downside to disabling pixmaps is that
  the animation will not be guaranteed to run at full speed - it may be
  rather jerky or slow.

  The second option is similar to the first option but applies to xss. Since
  xss uses a limited number of pixmaps, it should be possible to run xss
  with this option compiled on an X terminal. If you miss out this option
  then the display will be quite flickery.

  The third option defines the paper type you want to use in the PS dumps.
  If it is defined then xpgs and vpgs will use the international standard
  A4, otherwise they will use the US letter size (8.5x11).

  The final option (SILLYRAND) is defined when the random number generator,
  used by sisgen, vpgs & sisgen, has a poor distribution in the lower bits.
  For instance, the numbers returned may alternate between odd and even.
  This returns in a SIRDS which looks stripy. In fact if the backgrounds of
  the SIRDS does not like very random then you should try recompiling the
  programs with the option defined.

Unix machines
=============
There are two alternatives:

1) Copy the Makefile.std to Makefile, eg "cp Makefile.std Makefile". Then
   edit the Makefile according to the computer you're using by commenting
   out and putting in the compiler options appropriately. Make sure that the
   paths to the X stuff is correct.

   Execute the command "make" and all is done. Copy the data files,
   executables and man pages to their usual places, eg.
   /usr/local/lib/xpgs/polyh, /usr/local/bin & /usr/local/man/man6 if you
   have sufficient privilege otherwise put them in your own directory tree.

2) Edit the Imakefile putting in the install paths. Add any compiler options
   you deem necessary.

   Execute the commands "xmkmf" and "make". If you wish to install the
   executables, man pages and data files then use "make install"

At runtime, you can define an environment variable XPGS_DIR to point to the
polyh files. Eg. use "XPGS_DIR=/usr/local/lib/xpgs/polyh; export XPGS_DIR"
for sh or ksh or bash and "setenv XPGS_DIR /usr/local/lib/xpgs/polyh" for
csh and its ilks.

DEC VMS machines
================
There are (also) two alternatives :

1) Edit the make.com and choose the options you want. Then just execute the
   command file make.com by "@make".

2) Edit descrip.mms. Then use either mms or mmk (Matt Madison's free
   alternative).

To run either define a global symbol for a foreign command, eg.
xpgs:==$disk:[user.bin]xpgs etc or use the command mcr eg. mcr []xpgs etc.
Note that if you want to use options that have capital (or uppercase)
letters then they must be quoted, eg. mcr []xpgs "-S" cub

At runtime, you can define a logical XPGS_DIR to point to the polyh files.
Use "define XPGS_DIR disk:[user.data.polyh]", for example.

Problems and notes
==================
From past experience, I know a lot of gcc installations (on Sun's especially)
are misconfigured: header files, etc are wrong.

So please check 1) that your compiler is properly installed and 2) the
header files are ANSI C compliant - that is they have the symbols specified
in K&R 2nd Ed and the standard libraries. I've put in a few hacks in misc.h
and pgs.h to circumvent some errors.

The only non standard C call (apart from Xlib) is to the select() function
(or in VMS lib$wait()) in xpgs.c for timing the animation. This and its
associated struct's should be declared and defined through Xos.h. The string
functions str*() are declared throughout using string.h.

