This file is for those who wants to hack the cutting-edge
Gauche sources from the git 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 git sources, instead of from
the distribution, you need to have the *latest* release of
Gauche installed on your machine, for it is required to generate
some C files.   If you don't have one, grab the release tarball
and install it.

You also need autoconf (2.69 or higher), automake, libtool and
pkg-config.  (Note on OSX users: XCode now only includes subset
of autotools.  You have to install full set either manually
or thru MacPorts or Homebrew.)

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

  % ./DIST gen

Afterwards, you just do the usual ./configure + make.  For
configure options, see the INSTALL file in the distribution
tarball (it is a generated file, so it's not in the repo).

In case if the latest release of Gauche can't be built on your
target machine but the fix is already in the HEAD, you need to
take more steps---you need the source with that fix, but in order
to build it, you need the latest release of Gauche installed,
which you can't.  If you stuck in this Catch-22 situation, you
have to generate tarball on other machines.  Find a Linux box
(or BSD, or most Unix box would do) and take the following steps:

  (1) Build and install the latest release of Gauche on that box
  (2) Clone the source on that box, and build the HEAD as explained
      above.
  (3) Run
        % ./DIST tgz
      This creates a tarball Gauche-$VERSION.tgz in the parent
      directory of the source tree.
  (4) Copy the created tarball to your target machine, untar,
      configure and build.  The created tarball includes generated
      files, so you don't need Gauche in this step.
      
Note for seasoned libtool/automake users: the git source tree
includes files that are usually generated automatically by
autotools, such as aclocal.m4, ltmain.sh, src/gauche/config.h.in,
etc.  Avoid clobbering these files, unless you're sure you want
to do so.  If your autotools version doesn't match mine, 
it tends to break.


On Windows
----------

The recommended way to build Gauche on Windows is mingw-w64 and
MSYS2.  If you want to build from git source, you need Gauche
of the latest release to be installed.  The easiest way is to
grab the windows installer from http://practical-scheme.net/gauche.
For the details of build procedure, see doc/HOWTO-mingw.txt.

You can build Gauche with cygwin; do it just like on Unix.

Some effort was made to build Gauche with MSVC.  You can find
project files under winnt.  Unfortunatley though, it is so
much pain to make it work and keep it updated with newer Gauche
source tree, and now they are quite obsolete.


[CROSS COMPILATION]

In a normal compilation, extension modules (ext/*) are build
using the new gosh just built in src/.  However, we can't
run src/gosh when we're cross compiling.  So you need to install
*this version of Gauche* compiled on your platform beforehand.
Then, configure with the ordinary cross-compiling options.


[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.  If you modify files listed below, be careful
not to introduce undesirable dependencies.

- The compiler (compile.scm) shouldn't depend on anything that
  are not compiled into the libgauche core.   An exception is
  util.match; it's ok since it is just a macro and all 'match'
  forms are expanded fully in precompilation.

- 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
  extensions compiled by gencomp.  This is because gencomp is
  run by HOSTGOSH and it may not be able to load the other
  extensions 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.


[CHANGELOGS]

We have ChangeLog file to record changes of new features, APIs, or
internal changes large enough so that other developers need to be
aware of.  Small changes like 'quick fix of the bug introduced
in the last commit', or documentation additions, don't need to
be recorded.

In the age of distributed development, ChangeLog seems becoming
obsolete, for it causes conflicts easily.  Yet I still see it worth,
for it is one-stop place where somebody who tries to grasp what was
changed since some point of time.  SCM's commit log doesn't replace
that role---commit logs comes with every commit, however little it
is, and those small trivial logs are just noise to those want to
know changes that matter.  Also, commit logs are inherently per-commit,
so it's not a good place to describe overall intention or a plan
of series of changes.

To keep ChangeLog in that role _and_ to be friendly to distributed
development, I suggest that you don't update ChangeLog unless you
feel you really want to.  If I see your change is better mentioned
in ChangeLog, I'll update it separately.
