X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/8ea6525e3a092b76256fbed7d6edbb0a1861aee1..d2e3c807dce62e70b2ccdaa86c8190b2661a45b4:/README-hacking diff --git a/README-hacking b/README-hacking index 988bd304..71680100 100644 --- a/README-hacking +++ b/README-hacking @@ -50,16 +50,17 @@ These requirements do not apply when building from a distribution tarball. ** Requirements -We've opted to keep only the highest-level sources in the repository. -This eases our maintenance burden, (fewer merges etc.), but imposes more +We've opted to keep only the highest-level sources in the repository. This +eases our maintenance burden, (fewer merges etc.), but imposes more requirements on anyone wishing to build from the just-checked-out sources. For example, you have to use the latest stable versions of the maintainer tools we depend upon, including: -- Automake - Autoconf +- Automake - Flex - Gettext +- Graphviz - Gzip - Perl - Rsync @@ -68,16 +69,16 @@ tools we depend upon, including: Valgrind is also highly recommended, if it supports your architecture. -Bison is written using Bison grammars, so there are bootstrapping -issues. The bootstrap script attempts to discover when the C code -generated from the grammars is out of date, and to bootstrap with an -out-of-date version of the C code, but the process is not foolproof. -Also, you may run into similar problems yourself if you modify Bison. +Bison is written using Bison grammars, so there are bootstrapping issues. +The bootstrap script attempts to discover when the C code generated from the +grammars is out of date, and to bootstrap with an out-of-date version of the +C code, but the process is not foolproof. Also, you may run into similar +problems yourself if you modify Bison. -Only building the initial full source tree will be a bit painful. -Later, after synchronizing from the repository a plain 'make' should -be sufficient. Note, however, that when gnulib is updated, running -'./bootstrap' again might be needed. +Only building the initial full source tree will be a bit painful. Later, +after synchronizing from the repository a plain 'make' should be sufficient. +Note, however, that when gnulib is updated, running './bootstrap' again +might be needed. ** First checkout @@ -175,6 +176,28 @@ decide whether to update. ** make check Use liberally. +** TESTSUITEFLAGS + +The default is for make check to run all tests sequentially. This can be +very time consumming when checking repeatedly or on slower setups. This can +be sped up in two ways: + +Using -j, in a make-like fashion, for example: + $ make check TESTSUITEFLAGS='-j8' + +Running only the tests of a certain category, as specified in the AT files +with AT_KEYWORDS([[category]]). Categories include: + - c++, for c++ parsers + - deprec, for tests concerning deprecated constructs. + - glr, for glr parsers + - java, for java parsers + - report, for automaton dumps + +To run a specific set of tests, use -k (for "keyword"). For example: + $ make check TESTSUITEFLAGS='-k c++' + +Both can be combined. + ** Typical errors If the test suite shows failures such as the following one