diff --git a/README-CVS.txt b/README-CVS.txt
index 4559434910716c0f4908dd550bec1ea0d8b8fee0..2f2d78b5970f6dc65c7ea48cb97a5dac961a86ab 100644
--- a/README-CVS.txt
+++ b/README-CVS.txt
@@ -1,143 +1,172 @@
-$Id: README-CVS.txt,v 1.15 2002/04/08 18:05:16 mikael%unix.pp.se Exp $
+$Id: README-CVS.txt,v 1.16 2002/04/11 01:24:48 mast Exp $
+
HOW TO BUILD PIKE FROM CVS
If you like to live at the bleeding edge you can download pike from CVS
-whith all the latest additions from the developers. There are two
+whith 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,
-ie. 7.0.x, 7.2.x, 7.4.x wheras the development branches have an odd
-minor version.
+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 cvs versions are under heavy development and
-have not been tested nearly as well as the offcial releases. You use
+have not been tested nearly as well as the offcial releases. You use
the code at YOUR OWN RISK.
There are a few simple steps to get pike from cvs:
+
1. Get a recent version of cvs.
+
2. Login to the cvs-server:
cvs -d :pserver:anon@cvs.roxen.com:/cvs login
- just hit enter on the password prompt
+ Just hit enter on the password prompt.
+
3. Check out the source:
cvs -z3 -d :pserver:anon@cvs.roxen.com:/cvs co Pike/7.3
- subistute 7.3 for whatever version you want to get.
+ substitute 7.3 for whatever version you want to get.
Building Pike from cvs, in addition to the requirements of a normal
-build, requires a working Pike. You will also need automake, gnu m4
+build, requires a working Pike. You will also need autoconf, gnu m4
and bison.
The top-level makefile (in this directory, not the src directory) has
all the magic you need to build pike directly from CVS. Just type
-'make'. It is preferable to build from the toplevel since it avoids
+'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, ie. install in build directory
+tinstall test install, i.e. install in build directory
verify run the testsuite
run_hilfe run hilfe without installing pike
+documentation build the reference documentation from the
+ source. See the refdoc subdirectory.
source prepare the source tree for compiliation without
the need for a Pike.
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
+ (if you have cvs write access). Please DO NOT
check in the generated files.
-cvsclean clean the source tree for cvs actions.
-
-You may also like to modify some variables in the beginning of the
-Makefile.
-
-If that doesn't work, or you like making things difficult for
-yourself, try the Old instructions:
-
-1) cd src ; ./run_autoconfig
+clean removes all the built binary files
+cvsclean removes all files that are generated automatically,
+ i.e. brings the tree back to the state as if it
+ were checked out from the CVS
+
+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.
+
+
+CONFIGURE OPTIONS AND BUILD VARIABLES
+
+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
+ --without-bignums)
+--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
+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
+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...
- Some options for ./configure are:
- --prefix=/foo/bar if you want to install Pike in /foo/bar,
- default is /usr/local.
- --without-gdbm compile without gdbm support
- --without-gmp compile without gmp support
- --without-rtldebug compile without runtime debugging
- --without-cdebug compile without debug symbols (-g)
- --without-debug compile without rtldbug and cdebug
- --without-threads compile without threads support (See
- below)
- --without-zlib compile without gzip compression libary
- support
- --without-dynamic-modules compile statically, no dynamic loading
- used. (makes 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.
- --without-copt compile without -O2
- --without-bignums disable support for large integers
- --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
-
- Use the above flags to make sure the configure script finds the
- gdbm and gmp libraries and include files if you need or want those
- modules. If the configure script doesn't find them, Pike will
- still compile, but without those modules.
-
-4) Run 'make depend'
+4. Run 'make depend'
This updates all the Makefile.in files in the source dir to contain
- the correct dependencies
+ the correct dependencies.
-5) If needed, edit config.h and Makefile to suit your purposes. I've
+5. If needed, edit config.h and Makefile to suit your purposes. I've
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
+ possible, use gnu make, gcc, gnu sed and bison.
-6) Run 'make'
+6. Run 'make'
This builds pike.
-7) Optionally, run 'make verify' to check that the compiled driver
+7. 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.
-8) If you want to install Pike, type 'make install'.
+8. If you want to install Pike, type 'make install'.
-After doing this, DO NOT, commit the generated files. They are placed
-in .cvsignore files so you shouldn't have to bother with them.
+After doing this, DO NOT commit the generated files. They are placed
+in .cvsignore files so you shouldn't have to bother with them.
-IF IT DOESN'T WORK:
+
+IF IT DOESN'T WORK
o Try again.
- 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:
+ 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
@@ -163,19 +192,18 @@ IF IT DOESN'T WORK:
BUGS
-If you find a bug in the interpreter, the first thing to do is to make
-sure the interpreter is compiled with PIKE_DEBUG defined. If not,
-recompile with PIKE_DEBUG 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:
+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 version of the driver. (Try pike --version or look in
- src/version.h)
+ 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 makes the interpreter bug.
+ 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.