summaryrefslogtreecommitdiff
path: root/support/splint/INSTALL
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /support/splint/INSTALL
Initial commit
Diffstat (limited to 'support/splint/INSTALL')
-rw-r--r--support/splint/INSTALL59
1 files changed, 59 insertions, 0 deletions
diff --git a/support/splint/INSTALL b/support/splint/INSTALL
new file mode 100644
index 0000000000..11e85736ed
--- /dev/null
+++ b/support/splint/INSTALL
@@ -0,0 +1,59 @@
+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 local 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. 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
+curent 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. \ No newline at end of file