= How to hack the cutting-edge Gauche

NOTE: 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 a C compiler supporting C11, e.g. `gcc` (>= 4.9) or `clang` (>= 3.3),
`autoconf` (>= 2.69), `automake` (>= 1.14.1),
`libtool` (>= 2.4.2), and `pkg-config` (>= 0.26).
(Note on macOS users: Xcode now only includes subset
of `autotools`.  You have to install full set either manually
or thru MacPorts or Homebrew.  Xcode's `libtool` *does not work*).

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

[source,console]
----
$ ./DIST gen
----

Afterwards, you just do the usual `./configure` + `make`.  For
configure options, see the link:INSTALL.adoc[].

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
+
[source,console]
----
$ ./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 https://practical-scheme.net/gauche.
For the details of build procedure, see link:doc/HOWTO-mingw.adoc[].

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 quite 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.

- `precomp`, `genstub`, `geninsn` shouldn't depend on the extension
  modules except the '`pre-loaded`' ones in `BUILD_GOSH`.

- An extension compiled by `precomp` shouldn't depend on other
  extensions compiled by `precomp`.  This is because `precomp` is
  run by `BUILD_GOSH` 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 link: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.


== CODING STYLE

We aren't picky about coding style, but adopt some Gauche-specific
style, especially for Gauche macros.  For Emacs users, such style is 
written in `.dir-locals.el` in the top source directory.  If you're
using lisp-local package (available from MELPA), Emacs will ask you to
apply the settings.  Answering with `!` causes Emacs to remember your
choice and the settings will be applied in future without asking.



