Re: [Xen-devel] Changeset / commit id not incorporated in build after switch to git

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-02-25 at 23:00 +0000, Sander Eikelenboom wrote:
> Hello Sander,

Talking to yourself is a sign of something or other I think ;-)

> Monday, February 25, 2013, 11:28:53 PM, you wrote:
> 
> > Date: Mon, 25 Feb 2013 23:28:53 +0100
> > From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
> > Organization: Eikelenboom IT services
> > X-Priority: 3 (Normal)
> > Message-ID: <1208255021.20130225232853@xxxxxxxxxxxxxx>
> > To: xen-devel <xen-devel@xxxxxxxxxxxxx>
> > Subject: Changeset / commit id not incorporated in build after switch to git
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> 
> > Hi All,
> 
> > After the switching from mercurial to git, the changeset isn't incorporated 
> > anymore in the build.
> > This makes error reports possibly a bit less verbose (xl dmesg, serial logs 
> > and xl info now omit the changeset (or commit) info)
> 
> > Git doesn't have the concept of changesets afaik and mercurial is, while 
> > deprecated, still used as mirror.
> 
> > So what would be wise:
> >    - just replace the changeset with the git commit sha-1 hash (always)
> >    - use changeset when a mercurial tree is detected or the last git commit 
> > sha-1 (and date ?) when a git tree is detected
> >    - make a separate "commit" entry besides the changeset and leave one 
> > undefined
> 
> > xen/Makefile currently has:
> 
> > # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> > include/xen/compile.h: include/xen/compile.h.in .banner
> >         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
> >             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
> >             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
> >             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
> >             -e 's/@@hostname@@/$(shell hostname)/g' \
> >             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | 
> > head -1)!g' \
> >             -e 's/@@version@@/$(XEN_VERSION)/g' \
> >             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
> >             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
> >             -e 's!@@changeset@@!$(shell ((hg parents --template 
> > "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template 
> > "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
> >             < include/xen/compile.h.in > $@.new
> >         @grep \" .banner >> $@.new
> >         @grep -v \" .banner
> >         @mv -f $@.new $@
> 
> > --
> > Sander
> 
> 
> 
> Perhaps use about the same as linux has in scripts/setlocalversion ?

This is what I was going to suggest. Actually, I had it in mind we
already did something like!

Anyway, I think including whatever information the VCS we are building
from supplied is the right answer and the way Linux does it seems useful
and appropriate (e.g. using the tag name, appending -dirty etc).

If we can also extend that to do something sensible in the tarball case
then even better!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel