Installation notes:

Most of the development of ACS was done on a NeXT with Gnu C++,
2.2.2.  I have also compiled it successfully on several other
systems, listed at the end of this file.  Other users have ported
ACS to several other systems.  Some of the files are included in
the distribution.  They may not have been tested in the latest
release.  It should compile with any ANSI C or C++ compiler.  Future
versions will require C++.  It should produce no warnings when
compiled with the switches in the supplied makefiles.

All source files are in the src directory.  I use subdirectories
for the .o files each supported machine.  This makes it possible
to install it on several different machines all sharing the same
file system.

To avoid maintaining multiple versions of Makefiles, I have broken
them up to parts that must be concatenated: Make1.*, Make2.*,
Make3.*.  In general, to make a Makefile for your system, cat one
of each.  See the Makefile for details.  I have automated this for
some systems.  Just "make your-machine", if it is one that is
supported.  This will make the appropriate Makefile, cd to where
the .o's go and run make from there.

For some (non-unix) systems with more primitive facilities, you
should first "make makefiles" which will make the subdirectories
and the Makefiles.

We assume that make will follow "VPATH" to find the sources.  This
system makes it possible to manage several platforms on a single
file system which may be NFS mounted to all the supported machines.
If your make does not support VPATH, there are three options.  The
preferred method on unix based systems is to cd to where the
.o's go and type "ln -s ../*.[ch] .".  This will set up links so
the Makefiles will work as intended.  In some cases we have set up
the Makefile to do this automatically.  The second method, which
may be needed on systems like MSDOS that don't have symbolic links
is to copy the .c and .h files to satisfy make.  The third option,
best where you have only one computer, is to move the machine
specific Makefile to the src directory and run make from there.

If your system is not supported, you may need to make a few new
files or edit a few existing files.  If it is a unix type system
the changes should be small.  You should probably start by picking
one of the supported systems and trying to make it for that.
Probably the "ultrix" port is the most generic, so that is a good
first guess.  If it compiles without errors (preferably without
warnings) you are all set.

Probably what will happen is that either a header file will be
missing or it will complain about missing prototypes for a few
functions.  If this happens you need to make some patches.  Suppose
you have a "foobiac" computer.  You should make a new file
"Make2.foobiac" that defines the compiler switches.  In CFLAGS,
you should define "FOOBIAC" to select your patches.  You should
change "Makefile" to make the directory "FOOBIAC" for the .o files
and the special "Makefile" in the "FOOBIAC" directory.  You should
also add a few lines so when you type "make foobiac" in the "src"
directory it does (cd FOOBIAC; make -k) to make the program.  Then
you should edit the _unix.h file to make the appropriate includes
and prototypes for your system.  Look at the files to see how we
handle the other systems.  This should be all you need for any
unix port.  If you do a port please share your patches so I can
add it to the distribution.

If you have a non-unix system you may also need to change "version.c"
and "version.h" and make some new files "_foobiac.c" and "_foobiac.h".
Look at the files for other systems for a guide to what should be
there.  How you handle the "makefile" will depend on the tools
you have.

Some files starting with "plot" contain plotting drivers are may
also need customization if you want a graphic display.  If all
you want are ASCII plots the files should be suitable as they are.

On a PC, you should have some version of "make".  For Borland C,
concatenate the files "Make1", "Make2.bc", and Make.depend to
"makefile".  Then change all ".o" extensions to ".obj".  The program
"sed" on unix systems will do this.  Type "make" from the directory
containing the sources.  Since I use SoftPC on a unix system for
this, I make links (in unix) from the MSDOS directory to the src
directory (..) to work around the fact that my PC make does not
support VPATH.  You may need to get a few unix style utility programs
if you don't have them already.  Probably the best approach for a
PC is to use the pre-compiled executable we supply.

You should place the file "acs.hlp" in any directory in PATH.
ACS uses the environment variable PATH to find it.  Usually the
best place is the same directory as the executable.

There should be NO non-portable code anywhere but the underscore
files and plot files.  The use of #ifdef to patch portability
problems should be restricted to the underscore and plot files.

The latest version of the program with executables, source,
documentation, and test cases is available by modem from (716)272-1645.
Login as "guest".  ACS is also available by anonymous ftp from
ee.rochester.edu or cs.rit.edu.

If you have questions send email to al@atd.rochester.ny.us,
davis@ee.rochester.edu or atd@cs.rit.edu.  You should register (by
email) if you want to know about updates and the future of ACS.
---------
ACS (this release) is known to work on ...
  NeXT (Motorola), NextStep 3.2, c++ (gcc) 2.2.2
  Sun Sparc-2, Sun-OS 4.1.3 and g++ 2.5.8 (not cc)
  SGI Indy, Irix 5.2, g++ 2.5.8, CC
  Dec-station, MIPS, ultrix, g++ (not cc)
  286 PC, MSDOS 5.00, Borland C++ 3.1
  Linux, (pentium) g++ 2.5.8
Users have supplied configuration info for older versions ...
  VAX, VMS, gcc
  IBM RS-6000, cc
  Dec Alpha, OSF, gcc (as ultrix)
  HP 700 series, HPUX, gcc
  PC, Freebsd or 386BSD, gcc
  PC, OS/2, gcc
These systems appear to have problems ...
  Amiga, gcc
