This file is for those who wants to hack the cutting-edge
Gauche sources from the CVS repository.  If you just want to
compile from the distribution, you don't need to read any further.


[TOOLS REQUIRED FOR BUILDING]

On Unix platforms
-----------------

In order to build Gauche from the CVS sources, instead of from
the distribution, you need to have autoconf 2.54 or higher.
The author using autoconf 2.57.

You also need to have the latest Gauche installed on your
machine, for it is required to generate some C files.
(see also CHANGING VM INSTRUCTIONS below).

The CVS source tree doesn't include "configure" scripts.
You can use the DIST script like the following to generate them.

  % ./DIST gen

Note for seasoned libtool/automake users: the CVS source tree
includes files that are usually generated automatically by
autotools, such as aclocal.m4, ltmain.sh, src/gauche/config.h.in,
etc.  Be careful not to clobber these files.  First, if your
autotools version doesn't match mine, it tends to break.
Second, those files are likely to be edited after generated,
in order to fix some build problem on certain platform.


On Windows/VisualC
------------------

Gauche build process largely relies on the code generation
during building, and it is lots of pain to adapt it for VC.
So we chose a hybrid approach; the source tree needs to be
prepaired on the Unix platform (or Cygwin) with pre-installed
Gauche so that the machine-generated files are included.
To prepare source tree, run 'DIST' command as the following:

  % ./DIST winvc

Once preparation is done, look for the VC solution file under
winnt/ subdirectory.  



[CHANGING VM INSTRUCTIONS]

As of 0.8.4, Gauche's compiler is written in Scheme and should
be compiled using the installed Gauche (host) itself.   If you
change VM instructions of the source tree (target), you may 
require extra step of compilation, since the host compiler's
output may not run on the target Gauche.

Generally, whenever you added new VM instructions, defined in
src/vminsn.scm, you need to take the following steps to get
the new version of working gosh:

   % cd src
   % gosh -ftest -fno-inline-globals ./gencomp compile.scm
   % gosh -ftest -fno-inline-globals ./gencomp scmlib.scm
   % gosh -ftest -fno-inline-globals ./gencomp objlib.scm
   % make
   % ./gosh -ftest ./gencomp compile.scm
   % ./gosh -ftest ./gencomp scmlib.scm
   % ./gosh -ftest ./gencomp objlib.scm
   % make

The first series of gencomp generates compiled Scheme files
that do not include code piece from host gosh.  If you allow
inlining globals, some built-in procedures are expanded in-line
using pre-compiled code vector stored in host gosh, whose
instruction set may differ from the target's.

The second series of gencomp re-generates compiled Scheme files
using the target gosh, enabling all optimizations.


Removing VM instructions is even more cumbersome.  Suppose you want to
remove a VM instruction WHATEVER.  First, you change compile.scm
so that it will never generate WHATEVER, then 'make' to build
an intermediate version of Gauche.   After that, you remove WHATEVER
from vminsn.scm and follow the above steps, but make sure you use
the intermediate version of Gauche in the steps [3] and [4]----if you
skip this intermediate steps, you'll get an error in the step [3]
since the host Gauche generates WHATEVER instruction, but cannot
dump it since it can't find the instruction in the target's
lib/gauche/vm/insn.scm.


Renaming VM instruction is equally cumbersome.  You have to take
two stages: Add the new instruction under the new name, first, then
remove the old instruction.


Maybe I could automate these steps later, for they are error-prone.


[DEPENDENCIES]

Quite a few files are generated by Gauche itself if you build
Gauche from scratch.  Consequently, there are qute a few nasty
dependency issues:

- The compiler (compile.scm) shouldn't depend on anything that
  are not compiled into the libgauche core.

- gencomp, genstub, geninsn shouldn't depend on the extension
  modules except the 'pre-loaded' ones in HOSTGOSH.  

- An extension compiled by gencomp shouldn't depend on other
  extension compiled by gencomp.  This is because gencomp is
  run by HOSTGOSH and it may not be able to load the other
  extension compiled for the target gosh.

- ext/xlink shouldn't depend on anything that requires loading
  extension modules, since it is called before all the extension
  modules are generated.

