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 autoconf 2.54 or higher.
The author using autoconf 2.69.

You also need to have the *latest* release of Gauche installed
on your machine, for it is required to generate some C files.

The git 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 git 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 may be edited after generated,
in order to fix some build problem on certain platforms.


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

The recommended way to build Gauche on Windows is MinGW/MSYS.
If you install MSYS enviornment and MinGW, you can build
Gauche just as on Unix; that is, run "./DIST gen" to generate
configure scripts, run "./configure", then make.

Alternatively, you can use src/mingw-dist.sh script.  Just run
it on MSYS shell:

  % sh src/mingw-dist.sh

The shell script assumes MinGW is installed in /mingw.  If not,
you need to tell the place by setting MINGWDIR environment variable.

You also want to have MinGW libiconv and zlib libraries, for they
enable full-functional gauche.charconv and rfc.zlib build.  (You
can build Gauche without them, but then those modules won't
work fully.)  Put the dlls in $MINGWDIR.

The mingw-dist.sh script builds Gauche binary and installs it
in ../Gauche-mingw-dist/Gauche.  It also copies MinGW runtime and
other dlls, so the directory becomes self-contained.  You can copy
the Gauche directory to anywhere and run Gauche/bin/gosh.

If you have WiX SDK, you can build Windows installer as well.
The easiest way is to use src/mingw-dist.sh script.
Make sure the WiX tools (candle.exe and light.exe) in your PATH,
and run this command on MSYS shell.

  % sh src/mingw-dist.sh --with-installer

Then you'll find MSI file under winnt/wix.

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.
