DEPENDENCIES
Building from CVS requires the same tools as building from a source
distribution (gnu m4, bison and a C compiler, suggested also GNU make
and libz), and then some. In addition to thosee requirements, you
need a working Pike, autoconf and gcc (to generate the dependency
files; another compiler can be used to do the actual compilation).
Not all autoconf versions meet Pike's requirements. Autoconf version
2.13 and 2.52 are known to work. Versions 2.53 through at least 2.57
are known to not work.
CHECKING OUT PIKE FROM CVS

install Compile and install in default location.
install_interactive Interactive install.
tinstall Test install, i.e. install in build directory.
verify Do a test install and run the testsuite with the

module directories.
documentation Build the reference documentation from the
source. See the refdoc subdirectory.
depend Build the files that tracks dependencies between
the source files. This is necessary to ensure
correct rebuilding if some of the source files
change, but not if you only intend to use the

from there, e.g. through the bin/pike script (see
below). These dumped modules are not used for
anything else. After this has been run once, any
changed Pike modules will be redumped
automatically by the main build targets.

those whose source files have changed.
snapshot Create a snapshot export tarball.
export Create a source dist and bump up the build number
(if you have cvs write access). Please do not
check in the generated files.

If you want to pass arguments to the configure script (see below), the
simplest way is to use the CONFIGUREARGS variable, like this:
make CONFIGUREARGS="--prefix=/usr/local/my-pike --with-security"
The arguments passed through CONFIGUREARGS are remembered in the build
tree and reused if CONFIGUREARGS is undefined or the empty string.
You therefore don't need to repeat them every time, but you can still
change them later if you like. There's a special case for the --help
argument: If CONFIGUREARGS is set to '--help' then the help text from
the configure script is shown and nothing else is done, and the stored
CONFIGUREARGS setting isn't affected.
The build targets also creates a script 'pike' in the bin subdirectory
which runs the built Pike directly without installing it first. If
you want to use Pike this way (which is mainly useful if you update
from CVS often), you should consider doing 'make dump_modules' to make
it start faster.
Some options for the configure script are:
--prefix=/foo/bar if you want to install Pike in /foo/bar,
default is /usr/local.
--without-gdbm compile without gdbm support
--without-bignums disable support for large integers
--without-gmp compile without gmp support (implies

the build dir. Make sure to use an absolute path! This creates the
Makefiles you need, e.g. Makefile from Makefile.in and machine.h
from machine.h.in. If you don't use an absolute path the debug
information will be all warped...

7) If you want to install Pike, write 'make install'. This will put
your Pike in <prefix>/pike/<version>/. This way, you can install
many Pike versions in parallell on the system if you want to. To
put it below <prefix> directly, as other packages usually do, run
'make INSTALLARGS="--traditional" install' instead.

If you find a bug in the interpreter, typically if Pike dumps core,
the first thing to do is to make sure it is compiled with the
--with-rtldebug configure flag. If not, reconfigure and recompile
with that and see if you get another error. When you've done this,
please report the bug to us at http://community.roxen.com/crunch/ and
include as much as you can muster of the following: