You should have received:

	README
	usage.doc
	Makefile
	defs.h
	fsm.c
	fsm.lex
	fsm-lex.c
	fsm.yacc
	test.c
	test.fsm
	vars.c
	prefix.c
	fsm.h

Second, DO NOT BLINDLY RUN make!  Read this file first!

There is a bug in some versions of make that causes it to get upset
over the Makefile.  This is known to be present in Sun release 4.0.3
and 4.1.  (Release 3.5 gets slightly upset but a noise message is the
only symptom; it does not exhibit the catastrophic misbehavior
described below.)  These buggy makes do not like Makefile rules like

	foo.fsm.c: foo.fsm
		fsm < foo.fsm > foo.fsm.c

With such a Makefile, the buggy sort of make will produce a garbage
message about "foo.fsm.c depends on itself" and then proceed to run
"cc -o foo.fsm foo.fsm.c", thus destroying your fsm source file.  If
you then run make again without replacing foo.fsm, it will complain
that "foo.fsm depends on itself" and run the command in the Makefile
rule.  Repeated runs of make alternate between these two behaviors - I
suspect the determining factor is simply which of foo.fsm and foo.fsm.c
is newer.

If you are saddled with such a make, my preferred solution is to get a
working make.  If you can't do that, rename foo.fsm to foo-fsm or some
such, fiddle the Makefile, and beat on your vendor to fix the bug.

That aside, you should adjust certain things to taste:

	- the CFLAGS in the Makefile almost certainly needs changing
	  (not many C compilers accept the -V flag I've added to ours).

	- prefix.c contains a #include that may need changing.  It
	  needs to be able to find fsm.h; as distributed, it uses
	  <fsm.h>, assuming that fsm.h is installed somewhere globally
	  accessible.  If you use "" delimiters and make this a path
	  name, make it an absolute path, because the #include is
	  copied verbatim into generated .c files, so it must work from
	  the directory that .c file is compiled in.

	- fsm.c contains a pathname pointing to prefix.c; this needs to
	  be an absolute pathname for reasons similar to those
	  mentioned above for <fsm.h>: fsm needs to be able to open
	  prefix.c regardless of where its current directory is when it
	  runs.

Once you're happy with these, *then* you can build it.  First you need
to rebuild the dependencies at the end of the makefile; to do this, run
`make depend'.  (If your C compiler doesn't understand the -M option,
such as some Ultrix compilers, you will need to edit the Makefile and
delete the dependencies at the end of it by hand.)  Then you can run
`make'.  This should rebuild the fsm generator.  You can also do `make
test', which should build the test program.  The test program takes
numbers as input; these can be decimal, octal, or hex, with the same
conventions for indicating bases as C uses (leading 0x means hex,
leading 0 means octal, otherwise decimal).  It then prints out the
numbers it sees in the input.

usage.doc is a file describing the syntax the fsm generator accepts as
input and what the calling conventions for the resulting C file are.

The only machines I'm certain this works on are our machines here:
stock 4.3BSD on VAXen, Sun releases from 3.5 through 4.1.3 (Sun-3 and
SPARC), and NeXT release 2.1.  It ought to work on others, but I don't
know just how portable it is.  I expect the most problems out of
machines with fundamenally different function call mechanisms.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu