Re: [Iverilog-devel] Add git commit information to version strings

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> --- Jeevan Varshney <jva...@ya...> wrote:
> 
>>     make dist TAG=<tagname>
> 
> Make sure you remember that a distribution does not contain any
> configuration information and the Makefiles are part of that, so it
> appears we will need to use the Makefiles from our build tree to do the
> make dist, but we want the version information to only apply to the
> distribution being built. We want the git build tree to reflect the latest
> version info. I don't think this is a big deal it just all has to be kept
> straight.

Yes, this is a little awkward. When I make a tagged snapshot, that
file contains so Makefile, but does contain the configure scripts.
There is an "auconf.sh" script that generates the configure and a
few other files. There is no "git" context in that case.

I think Jeevan's proposal (is that how you wish to be addressed?) is
to generate the version stamp from within a git context then copy
that information into the snapshot. There was some scripting to
automate that. I'm not sure if I like that idea or not. I don't know
yes.

> This does bring up a question. For snapshots and releases it's fairly easy
> to figure out what the version should be, follow the existing pattern
> 0.8.6, 0.9.devel (<snapshot date>), but what version is the latest git
> (either 0.8 or 0.9)? It would be nice is we could identify that the build
> was being done in a git repository and use the latest information possibly
> something like  0.8.6 + git(<latest git patch date>) and 0.9.devel +
> git(<...>). Ideally this would be done automatically without a bunch of
> extra files being regenerated (definitely avoid having to rerun autoconf).

I think the beauty of the "git describe" generated name is that it
includes all this information: It includes the most recent tag, the
distance from that tag, and a good hint which branch away from that
tag. That gives us enough information to pin a build down to an
exact commit. It makes sense to include that information in all
distributions, released or not.

So replace (<snapshot data>) with the git describe output and we're
there. I think that's what Jeevan did for us. The trick is getting
that information stamped into snapshots that are exported outside of
git: snapshots and releases.

> Something like:
> 
> git pull
> make
> <remakes any files changed in the pull and also the main driver programs
> that contain version information>
> 
> The version files should probably also be updated when we do a local
> commit, but while it could be useful, I think local changes (when we are
> working on bugs) should not trigger a version change. Can we distinguish
> between a main commit and a local commit? If so showing the version as
> "local" could be nice. We just have to make sure it gets switched to
> normal when the patch finally makes it into the main repository.

Here's what I get locally at the moment:

    s20080314-33-gad3a73f

The s20080314 is the closest tag,
the -33- is the distance, measured in commits, from that tag, and
the -gad3a73f is an abreviation of the head commit.
I think that completely identifies the source tree.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH+kXlrPt1Sc2b3ikRAu5yAKCl7ybEjeWQX25jRDqMG+BCsn5eKQCgtQ2H
OEk1d3J8+z+Ixigh4RB8aAM=
=MROc
-----END PGP SIGNATURE-----