
HOW TO BUILD PIKE FROM GIT

If you like to live at the bleeding edge you can download Pike from
git with all the latest additions from the developers.  There are two
major branches in the archive, the latest stable branch and latest
development branch.  Stable versions have an even minor version
number, i.e. 7.0.x, 7.2.x, 7.4.x, whereas the development branches
have an odd minor version.

Keep in mind that the git versions are under heavy development and
have not been tested nearly as well as the official releases.  You
use the code AT YOUR OWN RISK.


DEPENDENCIES

Building from git 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 GIT

1. Get a recent version of git (1.7.2 or later).

2. Clone the git repository with

         git clone git://pike-git.lysator.liu.se/pike.git


The top-level makefile (in this directory, not the src directory) has
all the magic you need to build Pike directly from git.  Just type
'make'.  It is preferable to build from the toplevel since it avoids
contaminating the source tree with object files and other generated
files.

Other interesting make targets are:

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
                    installed Pike.
just_verify         Run the testsuite directly with the Pike binary in
                    the build tree.
run_hilfe           Run hilfe without installing Pike.
pike                Build only the Pike core, do not recurse into 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
                    build tree once.  It's not run by default.
source              Prepare the source tree for compilation without
                    the need for a preexisting installed Pike.
force_autoconfig    Force a build of the configure scripts.  This is
                    useful e.g. if a new module directory is added in
                    the git.
force_configure     Force configure to be run (recursively).
reconfigure         Remove the cached results from previous configure
                    runs and rerun configure recursively. If you have
                    installed a new library and want Pike to detect it
                    then the simplest way is to use this target.
dump_modules        Dump the Pike modules directly in the build tree.
                    That makes Pike load faster if it's run directly
                    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.
undump_modules      Remove any modules dumped by dump_modules, and
                    remove the redump step described above.
force_dump_modules  Force all Pike modules to be redumped, not just
                    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 git write access).  Please do not
                    check in the generated files.
clean               Remove all the built binary files.
gitclean            Remove all files that are generated automatically,
                    i.e. bring the tree back to the state as if it
                    was checked out from the git.


CONFIGURE OPTIONS AND BUILD VARIABLES

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 git 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
--with-rtldebug           compile with runtime debug checks
--without-cdebug          compile without debug symbols (-g)
--with-debug              same as --with-rtldebug --with-cdebug
--without-debug           same as --without-rtldebug --without-cdebug
--without-copt            compile without -O2
--without-threads         compile without threads support (see
                          also the section 'If It Doesn't Work' below)
--without-zlib            compile without gzip compression libary
                          support
--without-dynamic-modules compile statically, no dynamic loading
                          used (makes the binary larger)
--without-mysql           compile without mysql support
--with-profiling          enables profiling Pike code but slows
                          down interpreter a little
--with-poll               use poll instead of select
--with-dmalloc            compile with memory tracking, makes Pike
                          very slow, use for debugging only.
--with-security           enable internal object security system


You might also want to set the following environment variables:

CFLAGS     Put extra flags for your C compiler here.
CPPFLAGS   Put extra flags for your C preprocessor here
           (such as -I/usr/gnu/include)
LDFLAGS    Put extra flags to your linker here, such as
           -L/usr/gnu/lib and -R/usr/gnu/lib


MANUAL BUILDING

Instructions if you want to do the build more manually:

1. cd src ; ./run_autoconfig
   This creates configure files and Makefile.in files.

2. Create a build directory an cd to it.  Do NOT build in the source
   dir, doing so will make it impossible to do 'make export' later.

3. Run the newly created configure file located in the src dir from
   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...

4. If needed, edit config.h and Makefile to suit your purposes.  We
   have tried to make it so that you don't have to change config.h or
   Makefile at all.  If you need to do what you consider 'unnecessary
   changes' then mail us and we'll try to fit it into configure.  If
   possible, use gnu make, gcc, gnu sed and bison.

5. Run 'make'
   This builds Pike.

6. Optionally, run 'make verify' to check that the compiled driver
   works as it should (might be a good idea).  This will take a little
   time and use quite a lot of memory, because the test program is
   quite large.  If everything works out fine no extra messages are
   written.

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.

After doing this, DO NOT commit the generated files.  They are placed
in .gitignore files so you shouldn't have to bother with them.


IF IT DOESN'T WORK

 o Try again.

 o Try running 'make depend'.

 o Your sh might be too buggy to run ./configure (this is the case on
   A/UX).  Try using bash, zsh or possibly ksh.  To use bash, first
   run /bin/sh and type:

   $ CONFIG_SHELL=full_path_for_bash
   $ export CONFIG_SHELL
   $ $CONFIG_SHELL ./configure

 o If you are not using GNU make, compile in the source dir rather
   than using a separate build dir.

 o ./configure relies heavily on sed, if you have several sed in your
   path try another sed (preferably gnu sed).

 o configure might have done something wrong, check machine.h and
   report any errors back to us.

 o Your gmp/gdbm libraries might not be working or incorrectly
   installed; start over by running configure with the appropriate
   --without-xxx arguments.  Also note that threads might give
   problems with I/O and signals.  If so you need to run configure
   --without-threads.

 o Try a different compiler, malloc, compiler-compiler and/or make
   (if you have any other).


BUGS

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:

  o The Pike version.  (Try pike --version or look in src/version.h)
  o What kind of system hardware/software you use (OS, compiler, etc.)
  o The piece of code that crashes or bugs, preferably in a very
    small Pike-script with the bug isolated.  Please send a complete
    running example of something that causes the bug.
  o A description of what it is that bugs and when.
  o If you know how, then also give us a backtrace and dump of vital
    variables at the point of crash.
  o Or, if you found the error and corrected it, just send us the
    bugfix along with a description of what you did and why.
