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.
Marc
On Sep 24, 2017, at 11:03 PM, Faré fahree@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@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@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@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list