% Copyright 2012-2024, Alexander Shibakov
% This file is part of SPLinT
%
% SPLinT is free software: you can redistribute it and/or modify
% it under the terms of the GNU General Public License as published by
% the Free Software Foundation, either version 3 of the License, or
% (at your option) any later version.
%
% SPLinT is distributed in the hope that it will be useful,
% but WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
% GNU General Public License for more details.
%
% You should have received a copy of the GNU General Public License
% along with SPLinT.  If not, see <http://www.gnu.org/licenses/>.

There is no specific installation procedure to follow for SPLinT, although
there are a few dependencies to keep in mind. To build all the tools
in the package, you will need the usual suite of build tools (gcc,
make and friends), bison and flex (which usually come separately),
cweb and cwebmac.tex (supplied by the texlive-extra-utils in Mint, 
for example), and various fonts (cyrillic, such as lhr10, etc., found in
texlive-lang-cyrillic, and extra sizes of Computer Modern, supplied by
texlive-fonts-extra). The only purpose for the cyrillic fonts is to supply
a decent looking pair of `french quotes' or `guillemot's used in 
./tex/btokenset.sty.

As of version 3.0 of bison, the arrays yyprhs and yyrhs are no longer
exported as part of the bison output (indeed, they are no longer created
internally, either, so even writing a `plugin' would not help). A very
elaborate scheme, akin to the one used to extract the actions can be
implemented to reproduce those arrays but this seems too high a price
to pay for the arrogance and shortsightedness of bison maintainers and
developers. Therefore, as of this release, this package is only
intended to be used with bison version 2.7 or lower. So far, the
latest release of flex (2.5.39) is still compatible with SPLinT. In
case the system version of bison (and possibly, flex, in the future) is
incompatible with SPLinT, it is recommended that a local version is
compiled and used. For this purpose, make variables BISON_ROOT and
FLEX_ROOT can be set to the appropriate locations in makefile.loc. The
appropriate versions of bison and flex can be downloaded from
http://ftp.gnu.org/gnu/bison/ and http://flex.sourceforge.net/,
respectively. Due to the changes in glibc, the bison that comes with the
distribution (bison-2.7) needs to be patched first. Uncompress the archive
(bison-2.7.tar.gz) in some directory, copy bison_patch1 to it and run

    # patch -p0 < bison_patch1

The installation instructions in those packages are easy
to follow (the standard ./configure --prefix=<local bin directory> &&\ 
make && cp src/bison <local bin directory> && cp -a data/* \
<local bin directory>/share/bison should work).

The arrays (yyprhs and yyrhs) only affect the error reporting and the
`symbolic switch' output. The former dependence can be eliminated
(following the route taken by bison itself), however, the latter one
is a much more serious issue. If one is not using symbolic names for
grammar terms, the arrays can be ignored.  The approach taken by the
current version of bison is to use the state stack and yystos, yyr1,
and yyr2 arrays instead. Note that this is somewhat inconsistent with
the purpose of the debugging output since the error reporting routines
rely on the correct state of the state stack (yyssa) rather than on a
static set of grammar rules. Use an older version of bison.

The setup involved is minimal, but for the build procedure to work,
all the style files (that reside in ./tex and ./cweb) should be visible 
to \TeX\ (i.e. you should be able to \input them). Building everything
from scratch also requires Perl to be installed (see the scripts in the
./scripts directory). Building after the result of `make mostlyclean'
requires a C compiler and CWEB only.

* A note about make: while using make to perform quick rebuilds after
  minor modifications mostly works, this style of project is not very
  suitable for make's capabilities. Make is really good at
  codifying the build procedures that form a tree. In the case of
  SPLinT, the same commands often have to be run several times. What
  is even worse, running those commands repeatedly modifies the
  prerequisites for earlier targets. Thus, view make as simply a
  convenient way of recording every step needed to build the project
  and its various parts, not as an efficient building tool: it is
  always safer to say 'make distclean' and repeat the build.