[gambit-list] Automatic build system for Gambit

Marc Feeley feeley at iro.umontreal.ca
Fri Apr 1 09:34:59 EDT 2011


On 2011-04-01, at 8:11 AM, Paul Wolneykien wrote:

> 30.03.2011 13:34, Paul Wolneykien пишет:
>> May be the bootstrap compiler for v4.6.0 should be built from the
>> v4.5.3 sources using /usr/bin/gsc v4.5.3?
> 
>  Finally I've noticed the «[COMPILER CHANGES NEEDED FOR v4.6.0]»
> message in the git log. With that commit the bootstrap version of the
> compiler builds fine with gsc v4.3.5. The release version of compiler
> then build from the next commit.
> 
>  That two stage build process, however, doesn't work with automatic
> rebuilds: once a higher version of Gambit has been built it replaces the
> previous version and that, in turn, blocks the next compilation of the
> bootstrap compiler. So I'll try to make the building of the bootstrap
> compiler in some optional way.
> 
> 
>  Best regards,
> 
>    Paul.

I'm sorry if that wasn't clear.  Gambit is distributed as C files that are produced by itself from Scheme files.  This makes the bootstrap tricky.  When changes are made to the Gambit compiler it may produce different code that is incompatible with previous versions.  To make sure the C code was generated from the same version of the compiler, each release has a version number (the ___VERSION macro defined in the C files generated) which is checked by include/gambit.h when the C file is compiled by the C compiler.  So making a change to the Gambit compiler must go through these steps to change the version from X to Y:

1) Change the compiler logic so that it will generate in the .c files definitions of ___VERSION as Y.  This changed compiler is compiled with the Gambit compiler for version X, so the generated files define ___VERSION as X and this is as it should because include/gambit.h still checks that ___VERSION is X.  The executable of the new compiler is written to "gsc-comp".

2) Modify include/gambit.h so that it now checks that ___VERSION is Y.

3) Remove all the .c files that were previously generated (with ___VERSION defined as X).

4) With the new gsc-comp, compile the .scm files to produce .c files so that they now define ___VERSION as Y.

5) Change the definition of ___VERSION to Y in all the .c files that are hand written (mainly in lib/).

6) Compile all the .c files with the C compiler.

So if Gambit has gone through versions A, B, C, D and you want the latest version (D) and you have version A, you have to first build version B using A, then C using B, and finally D using C.  Each transition between versions must follow the steps above (or something equivalent).

Gambit's makefile was designed so that these steps are done automatically when you do a "make update".  I don't use it personally because I'm always working on the latest version.  I've heard that some users have problems with "make update", but I haven't had a good enough bug report and motivation to check this out.  If you are interested in making this work please let me know and I'll give you some help.

An alternative solution to your problem is to grab the latest tar ball and to build that.  Is this an option?  The "make update" is mainly useful for users who want to stay at the bleeding edge of the development, which is not the typical user.

And another option is to integrate your build scripts into the Gambit distribution (probably in the prebuilt subdirectory) so that when a new version of Gambit is released your type of build is done too.  I have a new 12 core multiprocessor running Linux and Virtual Box, and I'm planing to use it to do parallel builds when new releases come out.

Marc




More information about the Gambit-list mailing list