Hi,
I'm thinking of a semi-automatic system for building new releases of Gambit tracking the main Git repository at http://www.iro.umontreal.ca/~gambit/repo/gambit.git . I suppose the process as follows: when a new release tag is published, the procedure updates the local branch and build a new version of the Gambit, possibly with the help of a previously built one. The main problem with that is that I can't see a way to provide a consequently updated build environment as stated in http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Contributing_Patches_t.... The only thing that can be consequently updated is the clean local source tree (with no generated files) as it published at the main Git repository. That's because each build is handled in a separate environment constructing from scratch. However, the result of a previous build is available in the form of RPM package. So I've tried to use a previous version of Gambit (4.5.3) to build the fresh release (4.6.0) linking /usr/bin/gsc to gsc-comp in the source tree root: both `make bootstrap' and `make' finished with an error message about gsc version incompatibility.
Dear community, is it generally possible to build Gambit:
a) having only the sources published at the main Git repository?
b) having only a) and a previous version of Gambit installed?
If not, is the *-devel tarball is absolutely necessary to build Gambit? And if so, can it be prepared from the main Git repository?
Best regards,
Paul.
Afficher les réponses par date
The sources in the git repo are sufficient to build Gambit from scratch. I think the problem you are experiencing is that when you do a "git pull" the modification date of the .scm files is more recent than the corresponding .c file. So "make" thinks the .scm files have been modified since the last compilation by gsc-comp (to compile .scm -> .c).
Could you check if a
touch */*.c make
works?
By the way, it would be really nice to have an automatic build of Gambit on different systems (RPM, MacPorts, CYGWIN, etc). Is that something you want to do, or just for your own purposes?
Marc
On 2011-03-29, at 3:30 PM, Paul Wolneykien wrote:
Hi,
I'm thinking of a semi-automatic system for building new releases of Gambit tracking the main Git repository at http://www.iro.umontreal.ca/~gambit/repo/gambit.git . I suppose the process as follows: when a new release tag is published, the procedure updates the local branch and build a new version of the Gambit, possibly with the help of a previously built one. The main problem with that is that I can't see a way to provide a consequently updated build environment as stated in http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Contributing_Patches_t.... The only thing that can be consequently updated is the clean local source tree (with no generated files) as it published at the main Git repository. That's because each build is handled in a separate environment constructing from scratch. However, the result of a previous build is available in the form of RPM package. So I've tried to use a previous version of Gambit (4.5.3) to build the fresh release (4.6.0) linking /usr/bin/gsc to gsc-comp in the source tree root: both `make bootstrap' and `make' finished with an error message about gsc version incompatibility.
Dear community, is it generally possible to build Gambit:
a) having only the sources published at the main Git repository?
b) having only a) and a previous version of Gambit installed?
If not, is the *-devel tarball is absolutely necessary to build Gambit? And if so, can it be prepared from the main Git repository?
Best regards,
Paul.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
30.03.2011 01:47, Marc Feeley пишет:
The sources in the git repo are sufficient to build Gambit from scratch. I think the problem you are experiencing is that when you do a "git pull" the modification date of the .scm files is more recent than the corresponding .c file. So "make" thinks the .scm files have been modified since the last compilation by gsc-comp (to compile .scm -> .c).
Could you check if a
touch */*.c make
works?
No. It results in the following:
[builder@altair gambit-4.6.0]$ touch */*.c [builder@altair gambit-4.6.0]$ make making all in include ... make[1]: Leaving directory `/usr/src/RPM/BUILD/gambit-4.6.0/include' making all in lib make[1]: Entering directory `/usr/src/RPM/BUILD/gambit-4.6.0/lib' LD_LIBRARY_PATH=../lib:../gsi:../gsc: ../gsc-comp -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c -check _io.scm /bin/sh: ../gsc-comp: No such file or directory make[1]: *** [_io.c] Error 127 make[1]: Leaving directory `/usr/src/RPM/BUILD/gambit-4.6.0/lib' make: *** [all-recursive] Error 1
Same with `make bootstrap'. It looks for gsc-comp in the source root. So I've tried to use /usr/bin/gambit (v4.5.3) for that purpose, copying it to gsc-comp. It results in the following:
[builder@altair gambit-4.6.0]$ touch */*.c [builder@altair gambit-4.6.0]$ make making all in include make[1]: Entering directory `/usr/src/RPM/BUILD/gambit-4.6.0/include' ... make[1]: Leaving directory `/usr/src/RPM/BUILD/gambit-4.6.0/include' making all in lib make[1]: Entering directory `/usr/src/RPM/BUILD/gambit-4.6.0/lib' LD_LIBRARY_PATH=../lib:../gsi:../gsc: ../gsc-comp -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c -check _io.scm ... In file included from ../include/gambit.h:12:0, from _io.c:1342: ../include/gambit-not406000.h:1:2: error: #error "The version indicated in ___VERSION is not supported by gambit.h" ../include/gambit-not406000.h:2:2: error: #error "You are probably compiling C code generated by a Gambit compiler earlier or later than v4.6.0" ../include/gambit-not406000.h:3:2: error: #error "___VERSION will be set to 406000 to reduce other errors" make[1]: *** [_io.o] Error 1 make[1]: Leaving directory `/usr/src/RPM/BUILD/gambit-4.6.0/lib' make: *** [all-recursive] Error 1
Same with `make bootstrap'.
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?
By the way, it would be really nice to have an automatic build of Gambit on different systems (RPM, MacPorts, CYGWIN, etc). Is that something you want to do, or just for your own purposes?
Yes, it would be nice. I do it for the ALT Linux community purposes :) The central thing is building gambit-*.rpm directly from the git repo. When that is configured and works the repo updates and builds can be handled automatically (up to a build/packaging error). Our RPM packages have a lot of metadata: libraries/symbols provided/required by a package are automatically calculated during the build process. Having that rich set of metatada the ALTLinux RPM can be converted to a package for any other distro. When the build from a git repo process for x86 (32-64bit) would be set up, I'll try to port it to the ARM (Marvell) platform.
The Gear/Hasher build system:
is mostly a set of portable shell scripts. Potentially these tools can be ported to any system, including Mac. But as far as I know, some features of the Linux kernel are used to provide the necessary isolation for the build process.
Paul.
Marc
On 2011-03-29, at 3:30 PM, Paul Wolneykien wrote:
Hi,
I'm thinking of a semi-automatic system for building new releases of Gambit tracking the main Git repository at http://www.iro.umontreal.ca/~gambit/repo/gambit.git . I suppose the process as follows: when a new release tag is published, the procedure updates the local branch and build a new version of the Gambit, possibly with the help of a previously built one. The main problem with that is that I can't see a way to provide a consequently updated build environment as stated in http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Contributing_Patches_t.... The only thing that can be consequently updated is the clean local source tree (with no generated files) as it published at the main Git repository. That's because each build is handled in a separate environment constructing from scratch. However, the result of a previous build is available in the form of RPM package. So I've tried to use a previous version of Gambit (4.5.3) to build the fresh release (4.6.0) linking /usr/bin/gsc to gsc-comp in the source tree root: both `make bootstrap' and `make' finished with an error message about gsc version incompatibility.
Dear community, is it generally possible to build Gambit:
a) having only the sources published at the main Git repository?
b) having only a) and a previous version of Gambit installed?
If not, is the *-devel tarball is absolutely necessary to build Gambit? And if so, can it be prepared from the main Git repository?
Best regards,
Paul.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
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.
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
On Apr 1, 2011, at 9:34 AM, Marc Feeley wrote:
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.
In my admittedly limited experience, when make update leads to a build failure, doing make clean and starting over (including redoing configure) usually solves the problem. Presumably at that point the make update that failed (or lead to build failure) has updated sources to a state which is now usable by a later invocation of make.
warmest regards,
Ralph
Raffael Cavallaro raffaelcavallaro@me.com
On Fri, 2011-04-01 at 09:34 -0400, Marc Feeley wrote:
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",
That's something of an understatement!
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.
I can't help with the motivation, but I've added all the output from
./configure make make update
after untarring
gambc-v4_6_0-devel.tgz
to bug 146.
Brad
30.03.2011 01:47, Marc Feeley пишет:
The sources in the git repo are sufficient to build Gambit from scratch.
I've tried various commits/tags including HEAD and the initial commit of v4.0.0. but every version wants gsc-comp to compile itself. How can one build Gambit from scratch?
Best regards,
Paul.