[gambit-list] More precise versioning of Gambit?

Marc Feeley feeley at iro.umontreal.ca
Mon Sep 25 00:16:46 EDT 2017

Generating a version.scm file with the information is not ideal because it requires a working gsc-boot to compile it to C.  Moreover, it must be possible to build the system from a “release” (tar ball) with the basic build tools (sh, sed, make, gcc, …) *not* including git.  We can only assume git is available to the maintainers (this allows anyone to build Gambit from a release using basic tools on bare bones installations) and developers who modify Gambit.

Currently the configure script contains the release version (e.g. “v4.8.8”) in the symbol PACKAGE_VERSION and this is propagated and is available to all the makefiles.

To avoid rebuilding all of the runtime library after every commit, the file lib/version.h (not tracked by git) should be created by lib/makefile using PACKAGE_VERSION if it doesn’t already exist.  lib/makefile should check if git is available, and if so, the output of “git describe --tags” (with an appropriate “#define ___VERSION_STAMP” prefix or something) should overwrite lib/version.h if there are new commits since the version contained in that file.

There should be a build dependency from lib/version.h to lib/_kernel.o, so that any new commit will cause lib/_kernel.o and lib/libgambit.a to be rebuilt, but not other files in lib.

The current include/stamp.h approach to assign a precise “last commit timestamp” to the runtime system is not working well and should be abandonned.  It is a file tracked by git, which means that every commit (created with “make commit”) causes that file to change, which polutes the change history and makes merging commits more of a pain.  That information should be removed from the -v output.  A more interesting information would be the C compiler type and version.  That way, “gsc -v” would give a very good idea of the build context.


> On Sep 24, 2017, at 11:03 PM, Faré <fahree at gmail.com> wrote:
> OK, I'm willing to do the job, but I have many questions on how to do
> it right (i.e. in a way that will actually work for you, the
> maintainers). Can you help me do it?
> My preferred strategy would be as follows: a file version.scm will be
> dynamically generated by the build from `git describe --tags`, though
> care may be taken to only modify the file if the version changed.
> Already, a big question: which file should generate this information?
> * the configure script (it's the one that handles version right now;
> are we guaranteed to re-run it at every commit?)
> * the makefile.in (possible, but I'm not sure how to have make
> understand the dependency here)
> * some scheme file that make somehow always invokes last during the
> build (or first around the entire build) so the build doesn't use a
> stale file with an old version. I do that in Gerbil.
> I may have to modify the change-version target and/or the
> gsc/_parms.scm file to match the structure of what git describe
> --tags yields.
> If we do this in the configure script, I suspect no further change is
> necessary. If we don't I suspect there will be a lot of additional
> questions.
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Of all the things I've lost in life, I miss my mind the most...
>        — Ozzy Ozbourne
> On Sun, Sep 24, 2017 at 2:25 PM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
>> Definitely!  It could be added to the -v report to precisely identify the beast…
>> Marc
>>> On Sep 24, 2017, at 12:49 PM, Faré <fahree at gmail.com> wrote:
>>> Right now when I run gsi, it tells me I'm using gambit 4.8.8. But
>>> that's not quite right. If I use git describe --tags to ask git what
>>> I'm using it tells me v4.8.8-402-g300db59e, so some well-identified
>>> commit with 402 patchs on top of Gambit 4.8.8.
>>> I recently modified Gerbil to it remembers the exact version as
>>> identified by git describe --tags in its binaries. Basically, a file
>>> is generated during the build if git is available; when preparing a
>>> tarball for use without git, the file must be present. For release
>>> purposes, and so as to reuse github's builtin tarball capabilities, a
>>> release script creates and commits the magic version file
>>> before to tag the commit with the release version. Then to go back
>>> into development mode, the same script can "unrelease" the code
>>> and re-delete the file, adding it back to .gitignore, after the
>>> release was made.
>>> Are you interested in my porting the same mechanism to Gambit?
>>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
>>> A woman is not property, and husbands who think otherwise are living
>>> in a dreamworld.
>>>       — Robert Heinlein, "Time Enough For Love"
>>> _______________________________________________
>>> Gambit-list mailing list
>>> Gambit-list at iro.umontreal.ca
>>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

More information about the Gambit-list mailing list