iverilog-devel

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

[Jeevan V. <jva...@ya...>]

This is in regards to patch request 1935736 at http://sourceforge.net/tracker/index.php?func=detail&aid=193573&group_id=149850&atid=775999

Stephen Williams wrote:
> I'm a little concerned how this will impact the making of 
> snapshots. In particular, I use "get-archive" to export by tag. I 
> then extract the generated tar file, run the autoconf.sh script, 
> and re-tar to make the actual snapshot bundle.

> With this patch, the version.h header file is missing, and there is 
> no way to generate it once it is exported. We should discuss in the 
> iverilog-devel list what to do about this. Please follow up there 
> with any ideas you might have.

The git sources reveal that the git maintainers also use `git archive' to make a distribution tarball and use `git describe' to obtain a version string for their distribution.  They have a `dist' target in their Makefile which appends the file with the version to the tarball.  Also, instead of using a C include file for the version, like i did, they use a make include file; which allows them to automatically use the version in the tarball name and the RPM spec file.

Along those lines, i could add a `dist' target to Makefile.in that would automatically build a tarball for a given tag (or the head, by default) and add the version information file and an updated verilog.spec file to it.  One possible implementation would look like below.

In Makefile.in

    TAG ?= HEAD

    version.mk:
        # Put `VERSION = <output of git-describe $(TAG)>' in version.mk

    include version.mk

    all: ... version.mk
        ...
        cd driver; make VERSION=$(VERSION) $@

    verilog.spec: verilog.spec.in version.mk
        # Replace @@VERSION@@ with $(VERSION)

    SNAPSHOT = verilog-$(VERSION)
    dist: version.mk verilog.spec
        # Use git-archive $(TAG) to create $(SNAPSHOT).tar
        # Unpack to $(SNAPSHOT)
        # Copy version.mk and verilog.spec to $(SNAPSHOT)
        # Run autoconf.sh in $(SNAPSHOT)
        # Repack and compress $(SNAPSHOT) to $(SNAPSHOT).tar.gz

In driver/Makefile.in

    main.o: ... ../version.mk

The above example assumes that the verilog.spec file has been replaced with a verilog.spec.in file, and for simplicity's sake, there is just one version string instead of the two that i had in my patch.  The latter brings me to a question i have: should the "0.9.devel" version string be treated any differently than i did? I just left it as it was.

And, of course, anything else that needs to be done to make a snapshot can be added to the `dist' target.

In the end making a snapshot would look like below.

    make dist TAG=<tagname>




      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com

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

[Cary R. <cy...@ya...>]

--- 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.

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).

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.


Thanks for taking care of this!

Cary


      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com

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-----

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

[Larry D. <ldo...@re...>]

On Mon, Apr 07, 2008 at 09:03:49AM -0700, Stephen Williams wrote:
> Yes, this is a little awkward. When I make a tagged snapshot, that
> file contains so Makefile, but does contain the configure scripts.
                ^^no
> There is an "auconf.sh" script that generates the configure and a
> few other files. There is no "git" context in that case.

This is a great discussion, and welcome progress.
I do second Steve's concern that the snapshot process be
better supported.

I often make snapshots for my internal use.  My process used to be:

cp -a verilog /tmp/verilog-foo
cd /tmp/verilog-foo
rm -rf .git
sh autoconf.h
rm -r `find . -name autom4te.cache`
cd ..
tar -cvzf verilog-foo.tar.gz verilog-foo

but the latest git version string patch broke this.

I'm getting more comfortable working within the original git
tree [*], so I could imagine replacing the copy and rm .git
step with an in-place "tar --exclude=.git".  And having
a proper version tag in the result would certainly be nice.
Then a tidy-up step would be added at the end:
  rm `find . -name configure` lexor_keyword.cc version.h

I humbly request that a sensible way to make such a snapshot
be found, documented (scripted?), and close to what Steve does
for his public snapshots.

One more thing: the current version of version.h handling
breaks the write-protected pristine-source build concept.
The reference source tree should not be touched with an
out-of-tree configure/make.

       - Larry

[*] git bisect rocks!

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

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

> 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.

> Here's what I get locally at the moment:
> 
>     s20080314-33-gad3a73f

This sounds fine. If possible we want the snapshot to be just s20080314
and it looks like that is what you get when you specify a tag directly.
The other stuff appears to be specific to the local repository so it is
not that great at showing where the local repository is relative to the
master. I'm getting s20080314-164-g423bd07 and s20080314-263-ged7aba7 on
my two machines and both just had a git pull/make so they are synced. This
is likely because the last command "merge branch" is a local modification
and hence has a different ID. It would have been best if the two matched
so we could easily tell where people where.

Not perfect, but much better than what we had before.

Cary






      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com