Discussion:
[gambit-list] More precise versioning of Gambit?
Faré
2017-09-24 16:49:45 UTC
Permalink
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"
Bradley Lucier
2017-09-24 18:08:52 UTC
Permalink
I would like to have something like this. Brad
Marc Feeley
2017-09-24 18:25:33 UTC
Permalink
Definitely! It could be added to the -v report to precisely identify the beast…

Marc
Post by Faré
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Faré
2017-09-25 03:03:48 UTC
Permalink
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
Post by Marc Feeley
Definitely! It could be added to the -v report to precisely identify the beast…
Marc
Post by Faré
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc Feeley
2017-09-25 04:16:46 UTC
Permalink
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
Post by Faré
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
Post by Marc Feeley
Definitely! It could be added to the -v report to precisely identify the beast…
Marc
Post by Faré
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Loading...