[gambit-list] More precise versioning of Gambit?

Faré fahree at gmail.com
Sun Sep 24 23:03:48 EDT 2017


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